Uncomplicating new forge contributions

[Guinevere Larsen]

Hi Mark!

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:
> Hi,
>
> 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.

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 -_-

> - 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... 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.

> - 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 :)
> - 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
>
> - 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.

>
> - 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

> - 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?
>
> - 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 :)
> Cheers,
>
> Mark
>

-- 
Cheers,
Guinevere Larsen
It/she