Consider weighting issue credits by issue priority when ranking Marketplace organizations

while a working module with badly structured code that need to be refactored for improved readability and maintenance may be given "Normal" priority, but will require a large body of work to straighten it out.

An issue like that should be 'major' or in some cases 'critical' though, just it would be a task instead of a bug.

I like this idea and prefer the first option, the weak scale.

E.g.: A trivial spelling error in a class name may result in the project being unusable (i.e. of "Critical" importance),

In such cases the issue could also be tagged Novice and that tag could be used to alter the credit value? Or maybe have a set value for any issue tagged Novice?

With issues moving to GitLab, we are rebuilding the issue credit system, #3322116: Contribution records revamp →

GitLab does not allow adding UI elements to issue pages, so the crediting UI will be separated from the issue & MR UIs. This opens up a bit more screen real estate for more UX elements. We should keep this straightforward and easy for maintainers to update, but does allow more possibility to add a form element without competing with the rest of the issue UI.

The Priority:Normal/Critical/… labels are not guaranteed to exist in GitLab, 🌱 Using GitLab labels for issues on Drupal projects Active . Similarly, I don’t think we should use the novice tag or any other issue metadata directly. Explicit choices for crediting with descriptions and/or examples would be better to get maintainers more likely to apply them evenly and fairly across all projects.

The best way of thinking about this I’ve seen is impact for the project. Something might not have been prioritized, but still is a big benefit to many sites. Something might appear to be a big change, but was just linting rules being applied.

Weighting can only go so far, fixing one issue still reads as fixing one issue. Eventually, we might be able to put the impact/priority/complexity upfront on organization pages, showing what mix of issues they are attributed on.

From a thread on Slack:

The only issue I have with repurposing the priority field is that it could arguably be something people can hide behind. "Oh, it didn't use to mean that" or "I don't consider this a minor thing" and that anyone can change it.
You could catch people messing with said field, but the fact that it defaults to normal rather than minor would still lead to a lot of these non-issues getting more credit than they should.
Having a new maintainer-only field would make it really clear what the intent is and we could easily run some queries against that to find abuse.

In this case a checkbox could be: "This issue was trivial enough that it does not warrant any credit, e.g.: Fixing punctuation, spelling error, minor README changes, etc."

Then check it by default, making it a deliberate opt-out for maintainers when they accept a MR. If we see these being opted out of on the spammy issues we've been suffering from for the last few years, we can immediately take action because it clearly shows intent of gaming the system.

I don't think the checkbox is a huge effort to add and actually like that idea over the priority field. Just to illustrate, there are PHPCS issues being marked as critical or major... 🤣 https://www.drupal.org/project/issues/search?text=phpcs&projects=&projec... →

Might be worth considering all these changes for when we move issues to GitLab as well. I don't have a good view on how the credit system will work then (AFAIK it was still something on D.O?). We shouldn't be regressing on that part as we've spent so much time on it already 😉

Also, if you want it to be nicer you could also have a checkbox unchecked by default saying "This issue warrants credit", but obviously a more descriptive label and description. You get the idea, though.

Either way:

• No credit should be given, checked by default
• Credit should be given, unchecked by default

Any of the above would require active consent of the maintainer to provide credit. If we have that and we still find a bunch of non-issues being flagged as credit-worthy, it proves intent of gaming the system and we can take action far more quickly against the abusers.

I thought the credit checkboxes already default to off for new issues, so it ought to be 100% opt-in (unless an issue dates from before that change, then existing checkboxes weren't unchecked).

Yeah, having an extra "this issue should count for credit" flag as opt-in would be nice here. It would allow you to still credit the people who worked on an issue, but at the same time flag said issue as "this shouldn't go towards any marketplace rankings" to discourage the spam of readme fixes and the like.

Yeah, having an extra "this issue should count for credit" flag as opt-in would be nice here. It would allow you to still credit the people who worked on an issue, but at the same time flag said issue as "this shouldn't go towards any marketplace rankings" to discourage the spam of readme fixes and the like.

Oh I understand the difference now - so crediting but without awarding points to the organisation, and this happens across the whole issue not for individual contributors.

I don't think we'd ever use that for core, because even the most trivial issues are not always trivial to actually get committed, but do see how it would be useful for the endless README issues and similar, so yeah makes sense.

issue Complexity could be another scale to decide the credit scoring. The options could be something like:
Very easy, Easy, Moderate, Hard

We could automatically check the box for core "this issue should count for credit" but not for contrib.

+1 to what catch said in #13.

Re #15 We could simply check and hide it for core I would say :)