Improve the update experience

Great initiative, thanks for looking into this. One way to reduce the number of patches in the largest number of projects, could be to prioritize getting the issues with most used patches committed faster?

Collecting patch usage metric could be difficult, since for security concerns, many download the patch as a file.

Perhaps an "Issue Patch Star" feature could be considered?

[...]
Updated: 8 Jan 2022 at 22:12 CEST
⭐ Following 48 followers
⭐ Patch used (12) <<< Add this?

For security concerns, it shouldn't be externally exposed which users have "Patch starred" an issue.

Using patch download data could be really helpful as an additional method for prioritizing bug fixes, tasks and even smaller features. Unfortunately, I don't think we have that data at the moment, but I would hope it's something we could get.

I'm adding a few existing ideas from the ideas queue that are related.

Yes, but even if that data was available, I think it would not be too useful, since many users don't include patch link in their composer.json, but create a local patch copy file, out of safety concerns.

Also, if statistically based download metrics were used, those who use CI, and run it many times every day would be represented disproportionately.

This is why I suggest a new feature on drupal.org issues, the "Patch Star" placed below "Follow/Following"-toggle. It could be used as a filter, but also as a boost factor in searches.

Agreed that any data would have to be taken with a grain of salt. I don't think we need perfect, statistically accurate data but something that provides some direction. Right now we have low visibility to which patches are applied on sites.

What's worth noting too is that this data could only be useful for the short term because once we move to Gitlab, we would no longer have this data at all. This is another reason why we shouldn't rely solely on that.

There could be simpler solutions to this once we move issues to Gitlab. We could try to adopt a pattern where we encourage folks to add an emoji reaction to the issue as they download it as a patch in their project.

Ah yes, the issues are moving to Gitlab, where we can't configure the GUI ...

Sadly, the emojis would not be anonymous: Jane and Sven reacted with :patch_used: so not ideal, since it would divulge that this user probably is using that specific module on their web site(s).

For our sites, we have some reporting in place for patches and the results are aggregated in a dashboard. So this is possible, but I can tell you that it is very hard to aggregate the data even if you can force some rules (e.g. putting issue no. and comment id in the description in a certain format). Even in a small to medium sized agency like ours there are always some people who manage to "forget" the rules, which will mess up the results. Still, we find it useful to get a general idea about which patches we use. But for drupal.org, this would be a lot of work to implement properly, could be opt-in only (so potentially has the same problems as the module usage statistics that don't accurately reflect usage, especially on Drupal 9 and later where most sites use Composer), and is not of a lot of use when we switch to the MR based workflow exclusively at some point in the not so far future.

The "I use this MR" button sounds like an interesting idea in theory, but it is another thing that needs to be implemented on top of GitLab, people might forget to keep this updated, so the data is likely to be misleading, and it is prone to abuse, if you want to. E.g. when I start using a patch in our custom profile, I would have to set "I'm using this MR on 600 sites". If we want to support that, any user could easily misuse that to force the attention of the community at certain MRs they are interested in at a given time. I like to believe that our community would not do this, but the recent attempts at abusing the credit system by certain members of the community are a bad example and I think the business case of getting those issues fixed faster that you rely on is even more tempting than market place ranking. So I don't think this is something we should do.

Instead, I suggest we use what we already have. The number of people who follow an issue should be a good indicator about which patches are maybe more important than others. GitLab also has a way to up- and down-vote issues and they are using this to a certain degree during issue triage to prioritize resources. There is also a bot we could use to tag issues with a high number of followers or above a certain threshold of up-votes as more important than others. This might not be as accurate as a patch/MR usage dashboard, but it is most likely accurate enough for our use case and needs little to no time to implement, because most of what we need (including the data) is already there.

This is critical because, practically speaking, it blocks sites from being able to use AU, and is the primary reason we turn off contrib updates in the AU MVP despite the fact that really we want AU to update both.