Uncomplicating new forge contributions

[Mark Wielaard]

Hi Guinevere,

On Fri, Jan 16, 2026 at 02:47:28PM -0300, Guinevere Larsen wrote:
> I've just left a call with Arjun where we talked about this. we're
> both excited, and think this is a really good direction!
> 
> I have a few bits of specific feedback, but I'm not sure how
> relevant (or fixable) they are, and I think it's worth bringing up.
> 
> On 12/12/25 11:03 PM, Mark Wielaard wrote:
> >Claudio gave the forge talk (with me) at Cauldron and Gwen and Arjun
> >gave the Uncomplicating new contributions talk. I was hoping to merge
> >these topics because if we can show that new contributors are
> >productive through the forge then hopefully we can also make current
> >contributors more productive through the forge.
> >
> >If you don't mind I would like to discuss some of the points below on
> >the forge mailinglist: https://sourceware.org/mailman/listinfo/forge
> >So others can also give their input. Or maybe at the infrastructure
> >open office in about an hour (ehe, that just happened while writing
> >this email...) or the gnu toolchain one next week. But for now I don't
> >have any details, just this (likely incomplete) set of steps:
> >
> >- We need a contributing through the forge wiki page.
> >   We have https://gcc.gnu.org/wiki/ForgeExperiment but that is too
> >   much focussed on current contributors and their ideal setup.
> >   It would probably be good to have one wiki for each project with
> >   concrete steps for new contributors and people who you can email
> >   if you want a mentor to help you for that first contribution.
> 
> Yes, absolutely. I think it'd be good to add this page to the GDB
> wiki somewhere, and probably one for each project is good.

For elfutils we just added a sentence to the CONTRIBUTING file:
https://sourceware.org/cgit/elfutils/tree/CONTRIBUTING#n15

  Or look at https://forge.sourceware.org/elfutils/
  If you create an account there please send email to elfutils-devel
  to ask for a mentor who can make you an Collaborator so you can
  create a merge request against the elfutils project there. This will
  run various checks. And your mentor can help you create an email to
  sent to the mailinglist.

> If no one writes this in a couple of weeks, I'll take a crack at it.
> I wish I could do it earlier, but work stuff -_-

You could start with a simple paragraph like the above. And if there
are any takers extend it with the issues you encounter "mentoring"
your first contributor.

> >- Signup without an existing sourceware.org account.
> >   Current signups are just for people with an existing gcc/sourceware
> >   account. We should switch to open public signups. But we know that
> >   will cause thousand of spammers to sign up. So my idea is to switch
> >   new signups to be "restricted". That means they won't have any access
> >   to any organization/repository till they are added as Collaborator.
> >   I think for that we need to add new Teams for people that have just
> >   Read access (which should give them rights to create new merge
> >   requests).
> 
> Yeah...

So this part actually happened. You can now sign up with any email
address and get a restricted account. Which means you cannot do
anything because you cannot create a repository to work with through a
fork of an existing project. And a restricted user cannot fork any
project they aren't a Contributor to.

> One thing I talked with Arjun was: Would it be possible to
> assign a mentor to someone as they create their account?
> 
> say, part of the account creation process, if they don't use a
> sourceware email, is to require them to say which project they wish
> to contribute to, and automatically pick a mentor for them from a
> list of that project, emailing both to connect them. That way, from
> the forge point of view, the Mentors could act as a complex spam
> identifier: if the new user never answers us, we know it was
> probably spam, but if they answer, it was probably real and we can
> make them a collaborator.
> 
> From the point of view of users, it can remove the burden of
> reaching out to someone who they don't know, and since this is a
> human interaction, how close the mentoring is can be left to the 2
> participants.
> 
> And from the mentor point of view, this removes the bystander
> effect, we won't all be waiting for someone else to make a decision
> or worried about stepping on someone's toes.

Having a sign-up for project is a good idea. But that means we would
have to have a different sign up page/process.

I'll attend Fosdem end of the month and hope to meet up with the
Forgejo hackers who also will have a stand there. We should make a
list with ideas like this to see if they already have those kind of
processes or if they can give a hint how to tweak/hack forgejo to
provide them.

> >- So we need volunteers to add people as Collaborator. I am hoping you
> >   want to be the mentors mentioned above that do that. We need at
> >   least one per project. But we can of course also ask people to email
> >   forge@sourceware.org.
> Absolutely, I'm down to be a volunteer to mentor folks!
> I'm just pretty bad at looking at the website, so being pinged in
> emails would probably be important :)

Haha, that is they whole thing with our forge isn't it? We all have
our processes around email.

> >- Terms and conditions. Somewhere in the process we want to make clear
> >   what "the rules" are. Hopefully nothing scary. But we want to set
> >   the expectations. You should only use it for contributions you are
> >   actually allowed to submit to the project. Everything is public (or
> >   should be, you can currently set your profile or repo private, but
> >   that isn't allowed). You should be using a valid email addres. You
> >   are encouraged to run actions to check your contributions, but our
> >   resources are finite, so we are allowed to restrict your usage so
> >   others can use them to. etc. Hopefully all common sense. But maybe
> >   not what people expect when they have only used a proprietary forge.
> >
> >- Use commen names for the repos against which people should clone.
> >   current we use -mirror and -TEST which is a little confusing.  Since
> >   the bot can now keep repos in sync I think it would be more clear if
> >   we rename the project-TEST repo to just project.
>
> yeah, I agree with these 2. We gotta be mindful of how the T&C are
> written so that it doesn't look overly corporate and end up making
> people not read them... or at least, we should have a summary
> version somewhere

I'll try to come up with some text next week.

> >- batrachomyomachia, the forge-bot, can/will add a welcome message to
> >   the merge request. It does add a lot of text, lets see if we can
> >   compress that a bit.
> >
> >- It would be nice if with the welcome message the forge-bot also
> >   assigned a mentor/sponsor as reviewer.
> 
> Yeah, it could be the one assigning mentors, if we don't decide to
> do that upon first creation of account.

It might be something for more experienced contributors. Your first
merge request gets assigned to your initial mentor, but after three
the bot might just assign a random reviewer from some pool?

> >- We should add "small" action runner checks. e.g.
> >   - GNU-checkstyle (already added)
> >   - python black formatter (for gdb at least)
> >   - autoregen (like buildbot already has)
> >   - simple x86_64 build
> >   - some subset of tests that should always pass
> >   - full testsuite run? (might need mentor to interpret results)
> 
> I think most of it should be fine. I don't love the idea of a full
> testsuite run, because if it is relevant, the mentor should be
> asking for it already, and if it isn't, there's no real point
> spending the resources and then needing to interpret the
> result..........
> 
> but maybe I'm overthinking it and the resource expenditure wouldn't
> be so bad

Forgejo 14 (to be installed this weekend) seems to have some "Trust
Management" improvements that might help with this:
https://forgejo.org/2026-01-release-v14-0/#pull-request-trust-management

  Forgejo’s ability to “Approve” actions execution from a pull request
  has been enhanced with new options to approve once, always, and deny
  execution. Once a user is approved for execution, abuse can also be
  managed by revoking access for execution.

> >- Figure out how people can run these themselves (or again make mentor
> >   trigger them).
> I wonder if it could make sense to have some kind of role like
> "first timer" or whatever, which limits you to cloning one repo and
> opening like 2 or 3 MRs, and can't run those runner checks, so they
> can't exhaust our resources early, and once they have one patch
> merged they can be upgraded to "collaborator" and run these by
> themselves?

Forgejo has a First time contributor label but I don't fully
understand how that works. But I believe with the above "Trust
Management" that can be used to make First time contributors
untrusted for automatic action execution.

> >- Likewise for the /submit command that the user uses to make the
> >   forge-bot sent the patch as email to the list. Might be good if the
> >   mentor does that for the first patch.
> Yeah I agree here. Basically same thoughts as above
> >Please let me know which steps make sense, what is messing and how to
> >make things even simpler for new (forge) contributors.
> I think anything past what you've written here is a shot in the
> dark. Once this is working, then we'll be able to figure out if we
> can do even more, but just this will already be such a massive
> improvement that it is hard to tell what else we could do at once :)

Yeah, I am going through my first new contribution through the forge
for elfutils right now. I must admit that as mentor am more confused
about how things work than the new contributor :)

Hopefully our first new contributors will forgive us that our
processes aren't perfect yet and help us write better forge
contributor guides.

Cheers,

Mark