Draft Proposal: Django Mergers with Terms

[django]

Draft Proposal: Django Mergers with Terms

[timgraham]

I don't know. It feels like the DSF would be promoting forced, unpaid labor to ask people to volunteer as guest mergers and then require them to be active every week. I would be surprised if many people volunteer for this, but I could be wrong.

[jarshwah]

I like the idea you've raised of a Guest merger. It tries to attract new talent under a mentoring type of arrangement. I wonder how it might work in practise though. Would the core mergers be able to put in the time to effectively train the juniors? I think this could open up "core work" to a more diverse group

Term limits I think are necessary, with an explicit opt in to continue into the next term, and the possibility to pick the role back up after stepping down for some time.

Some specific criticisms:

• Mergers should get commit access, otherwise what's the point
• A limit of 2 terms as a guest seems strange, but seems like a guard against forever-guest-merger
• After each release, the release manager or tech board should open a call for mergers (core and guest) which serves as the opt in trigger

[collinanderson]

I like the idea you've raised of a Guest merger. It tries to attract new talent under a mentoring type of arrangement. I wonder how it might work in practise though. Would the core mergers be able to put in the time to effectively train the juniors? I think this could open up "core work" to a more diverse group

Yeah, exactly. I'm curious what the current active core devs think.

Term limits I think are necessary, with an explicit opt in to continue into the next term, and the possibility to pick the role back up after stepping down for some time.

"Term limits" is confusing. "Term limit" usually means restricting the number of terms. So yes terms and limits, but no "term limits" for Core Mergers.

But, yes, I think it needs to be really easy to step down (and automatic), and really easy to pick up the role again. (And I think easy-role-pickup makes sense from a project point of view: We know these people are really good when they work Django, and if they want to be regularly active again, great!)

Mergers should get commit access, otherwise what's the point

Well, my thought is, especially for "Guest Mergers" you could still do a lot of ticket triage and patch review, which is really helpful and worth recognition, without technically needing commit access.

A limit of 2 terms as a guest seems strange, but seems like a guard against forever-guest-merger

2 consecutive terms. Maybe not really necessary, but yeah, my thought is to show a clear path to Core Merger: do two guest merger terms in a row and you're basically in (assuming the Core Mergers want to keep you around). I'm also starting to second-guess the 8-month length of Guest Merger, maybe we should allow beginners to only need to commit to 4 months?

After each release, the release manager or tech board should open a call for mergers (core and guest) which serves as the opt in trigger

Seems fine to me.

[collinanderson]

My thinking is the Guest Merger is sort of a training period, and to get trained you need to be at least somewhat active. My hope is to provide people a clear path to being Core Mergers which requires being somewhat active. If anything I could see the 9-month term being shortened to 3-4 months, so they don't need to be super active for as long of a period of time.

[carltongibson]

Closing as part of the (resolved) DEP 10 discussion. Thanks all.