Contribution credits for project releases

For UI changes, we want to consider both:

• How would this show up on user pages?
• If/how would this show up on organization pages?

When I read this title, I thought it meant "show which people contributed to a release (and perhaps how much)" — which would be an excellent way to get people excited I think? ("I helped ship Drupal 8.5.3!")

show which people contributed to a release (and perhaps how much)

#2940427: Keep track of commits in a release is the first step for that. Then we can know who got credited in a release’s issues.

I believe #2905934: Contribution credit for project releases is a duplicate of this one, but @catch created both so not sure.

A few notes:

1. Project usage should definitely be a factor.
    

2. It should only be published releases. This is probably implied but we shouldn't forget. :)
    

3. We do not want to encourage spamming of many releases. I think anything more than 1-2 releases per branch per month per project overall should be automatically flagged for auditing (possibly hardcode-excluding core since this will happen semi-annually and we have strict governance about it, and also excluding published security releases since having contrib SAs on two out of the four windows in a given month is totally possible, and furthermore the Security Team governs that so we don't need the DA to).
    

4. Per @drumm's above comment, we should also consider the number of commits between releases as a possible factor to audit if the number is repeatedly well below the community mean.
    

5. Related: Possibly average commits per release affects the algorithm factor for the project. (Like if you make one commit per release on average, the work you're putting into each release is less.) OTOH security releases are still the most work for the release manager (edit: at least for core, and probably also for contrib since you have to coordinate with the Security Team), so those should not be punished for only containing 1-5 commits.
    

6. alpha1 releases are actually the most work of any core release type, except possibly beta1 or the stable tag for core majors. So we shouldn't exclude pre-release milestones, although I'm not sure whether core is special or not here. Encouraging having a stable release of a given branch is good, though.
    

7. Core releases have multiple contributors. If we permit the same for contrib, there is risk of this also getting gamed, or of people misunderstanding that it shouldn't be a duplicate of the issue contributors or w/e. OTOH if (say) @quietone writes all the release notes and I contribute nothing except pushing the tag, she's actually done more work on the release than me.

   It doesn't need to be MVP -- that could just be the release node author -- but eventually we should have a crediting UI on release nodes. That would either need to wait on decoupling the crediting widget from comments, or use something like the SA workaround until it's decoupled from comments. Edit: Remembered that while core has a 1:1 relationship between tag and release node author, this is not true in general. So it's the release node author we probably care about, since that's got access governance for any given project.
    

8. If we can mitigate gaming appropriately, a release should be of more value to a given project than a non-release issue commit to the same project. For context, my direct work on the RTBC queue drops off significantly during the 6-8 weeks before a minor release, because my hours go into behind-the-scenes work on the milestones and governance related thereto. My best guess (which I've given as an "FYI" to potential employers) is that my RTBC queue issue credits will drop by as much as 80-90% during the time I'm focusing on minor release prep.
    

9. I also reflected on whether patch vs. minor vs. major releases should get different credits. This might be something to defer to a future discussion, since we also don't want to encourage spamming minor or major releases when it's patch-level changes, and that also can't be audited simply the same way the raw count can be. (And/or, we consider special-casing core.)

The points about release creation rate and release type might also ideally be added to our proposed "maintenance best practices" contribution policy, and also considered for project health metrics for post-MVP Project Browser.

Thanks for this interesting topic and discussion. A few notes on #7:

3. That's how I feel about frequency of releases, but there are a lot of folks in the community that disagree with us. For many folks (I believe I've heard @larowlan say things like this): "releases are cheap, don't make me apply patches. If you commit a fix, cut a new release." I suspect a lot of people would object to the idea of "flagging for audit" if you have more than 2 releases a month. To me, this makes this whole idea potentially problematic. We want to give credit where due, but we also don't want to encourage lots of releases just to get more credit. If different maintainers have different standards / culture around release frequency, do we want to punish those of us that would rather batch a lot of fixes together (so our user base spends less effort on updates) and reward the "release early, release often" crowd?

As I read through the details of the complications in 4-7 and 9 I'm finding myself unsure on the idea of crediting releases at all. If a release has a lot of commits and fixed a lot of issues, there are a lot of issue credits "in" it. If the release only fixes 1 thing, there's only 1 issue credit in it. Why are we trying to figure out how many commits a release has so we can re-credit all those commits again as a "bigger" release vs. a smaller one? Why not continue to credit the issues themselves? Yes, because creating the release node itself is also some effort. In some cases, a lot of effort. But it varies a ton by project in all sorts of dimensions. Any system we build for this is going to run into a bunch of thorny messes because of those differences, and I'm not sure "we" want to weigh into those debates as a tool chain.

In the case of core, we already create issues to credit non-code stuff like meeting participation. If anyone doubted that the core release managers contribute a lot, we could always create more plan issues to give more credit for that unseen effort on release notes, etc. 😅 Ditto the concerns in point 8: if RM efforts on the RTBC queue plummet during minor release prep, seems like that's because you're working on plan issues, or "policy, no patch" or whatever, and can be getting credited over there. I don't think we can have release crediting itself deal with that unseen effort. If more of it needs to be surfaced as issue credits, we can do that already.

Stepping back, we want to:
a. Encourage meaningful contributions.
b. Acknowledge all the effort that goes into making Drupal possible and available.
c. Encourage project maintainers to fix things and make their projects better.

I believe we sufficiently handle c. via issue credits. I think we could address B by making more use of plan issues for creating specific releases. If we're going to make an issue to credit people with 2-60 minutes of participation in a weekly meeting, why not make a "credit issue" for the work of actually cutting a specific release? I already tend to do this in projects I maintain, not for credit, but to document a plan for a next release milestone. If that's the main thing this issue is trying to address (the work of creating the release node itself (and all that goes into it)), seems we could already solve it with existing plumbing.

So tentatively -1 on this whole proposal, but definitely interested in it, and totally open to the possibility we should still do it. 😅

p.s. semi-related, I'm in favor of weighing issue credits by priority. That would help solve things like "I spent all week on 1 nasty bug" vs. "I knocked out 50 automated minor fixes this week". Insofar as we want to use release credits to honor some of the extra work that goes into security releases, we could be somewhat handling that via issue priorities, instead. But this is another complicated can of worms, and I'll be the first to admit there are a lot of "thorny messes" in this idea, too. 😂

Just seeing this. My only 2 cents is I wouldn’t want to be penalized for creating more than 2 releases in a month because I can see valid reasons for that happening at least occasionally.