Contribution credits for project releases

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 two contrib security in a row in a given month is totally possible but 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.
    

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 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 for core majors. So we shouldn't exclude pre-release milestones entirely, although I'm not sure whether core is special or not.
    

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

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

Weighting issues by priority is ✨ Consider weighting issue credits by issue priority when ranking Marketplace organizations Active .

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.

I agree with @dww on this one - it's reasonable to cut a patch release every time you fix a bug and we're starting to see things like https://github.com/semantic-release/semantic-release for automating releases. I am quite attached to core's monthly patch release cycle, but I could absolutely see a contrib project doing six bugfix releases in a week, then nothing for three months, then another four releases etc. It would also be extra work to monitor this.

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.

Bumping this again. I very often run into contrib bugs where a fix has been committed but there's not been a release since, if this provides a small incentive to tag a new release that would be a good thing.

I think abuse could be monitored via view that shows projects with a count of releases or similar, if something has a ridiculous number of releases, it would be at the top of the list and then could be looked at. But also this is much more work than opening issues, crediting yourself, and marking them fixed, which maintainers could easily do already.

+ 1 for this.

I think there's a bit too much worrying about abuse. In the bigger picture, it will be pretty obvious if a module maintainer starts releasing pointlessly, to game the system. Some sane max. release limits, before a project gets flagged makes sense, and should prevent abuse. Also, users of that module will most likely notice too frequent pointless updates, and complain.

I agree that quite often, great improvements have been committed to the dev-version of a contrib module, but it may take years before it gets officially released ... So if giving credit for a release helps speed up the release cadence of projects, I am all for it.

Agree that incentivizing the could have a positive impact and those who decide to abuse it will likely be called out.

I read the comments a few days ago and gave myself some time to think on this. I think automatically giving credit for a release can have an overall positive effect. So, instead of waiting for solutions to the edge cases and gaming we should make a trial of this for a couple of months and then decide next steps. Start with giving credit for a stable release only to keep things simple. And create the view suggested in #12. That should be enough to keep an eye on abuse during the trial phase. There is already a dedicated group of people assisting with abuse, so let's give them a tool to help with this one.

For organization ranking, we can weight this based on project usage, like we do for issues.

Before getting into crediting organizations, we want to make sure people are credited. That means making a release should be highlighted on your user profile page, like https://www.drupal.org/u/catch → . A couple ideas to start:

• A separate listing of “Releases made”, like “Projects maintained,” would be the most straightforward. For medium to large screens, could position to the right of “Projects maintained.” Would need to either count for each project, or see if we need a “more” link if listing them all.
• Merging in with “Projects maintained,” adding a count, would save some screen real-estate. Would need to think about what, if anything, to do when someone who made releases is no longer a maintainer of a project.

Once people are credited, this should guide how credit appears on organization pages like https://www.drupal.org/tag1-consulting → .

For storing the organization metadata, it would be most straightforward to have a field like “Supporting organizations” on projects. That could be a straightforward entity reference field; I don’t think “How they helped” would be necessary for releases. Using the issue-style organization/customer setup would be overly-complicated, but if we do need that, we can follow what we did for security advisories.

Once we have the data for organizations, we should pick where/how to show it on release pages.

For storing the organization metadata, it would be most straightforward to have a field like “Supporting organizations” on projects

This feels absolutely fine for contrib, but possibly not appropriate for core, where there are people funded - either part time, or full time, or for one of those for shorter periods, to work full time on core but who aren't core committers. They'd then not be able to add their organisation, and they'd never be making releases, but the 'supporting organisations' would look lop-sided.

A possible solution to this would be to have the field, but not make it visible to regular anonymous/authenticated users - maybe just admins and project maintainers?

However having typed that, this starts to feel as complicated as adding the credit attribution widget on release nodes.

Perhaps simply being maintainer on a project should also give credit?

As it is now, an organization with a person such as myself, not maintaining any projects, with limited coding skills and therefore fairly simple MR's, is placed above a veteran Drupal core contributor and project maintainer such as @dww, which I don't think is fair.

The organization https://www.drupal.org/3281d-consulting → where https://www.drupal.org/u/dww → belongs to is placed at around #105 (page 3) and lower than Ardea, at around #87:

Ardea
#87: 777 issue credits, 1 person
https://www.drupal.org/organizations?page=1 →

3281d Consulting
#105: 531 issue credits, 1 person
https://www.drupal.org/organizations?page=2 →

Proposed resolution

Simply being maintainer on a project should also give credit, due to the extra tasks it requires, and sign of expertise it signals. The credit could be calculated using the number of installs, and maybe only be considered, if the project has more than for example 100 installations, to prevent gaming of the system.

The result should be that 3281d Consulting is placed on the first page, among the first #50 organizations, perhaps with a text like this, including the projects maintained:

3281d Consulting

531 issue credits, 93 projects maintained, 1 person