Issues as valued contributions

[jayvdb]

Creating issues and responding to issues should be valued.

This may be a key to helping detect 'maintainer' accurately as they will often be identifying new features and finding bugs. In a larger org, the commits will be by someone else, with the senior members providing code reviews.

This would need to be disabled when the repo is using a different issue tracking system, and that could be detected by having significantly fewer issues than PRs

[lourot]

Thanks for the issue :) I agree that some issues are great contributions.

Some are not though. I have myself been guilty sometimes of asking without properly reading the very clear documentation. I imagine many such issues on popular projects like https://github.com/facebook/react, although probably they get flagged as "not an issue".

Still we need to either take only really outstanding issues into account, or separate them from coding contributions in our UI, or it'll create a lot visual noise.

Also for getting commits in a project that you don't own, your work needs to be accepted by another human being and sometimes by a CI system. For issues there is no filter though, which is why I tend to think that the ratio of good commits is way higher than the ratio of good issues.

So it's tricky but not impossible and we could just trust files like https://github.com/AurelienLourot/ghuser.io/blob/master/.all-contributorsrc

(By the way I discovered all-contributors thanks to you, many thanks!)

[jayvdb]

To get things started, what about only counting issues which result in a commit? That is available in the GitHub metadata for issues, and indicates it was valuable.

Of course there are many other types of valuable issues, but starting with the easiest will allow issues to be considered in the designation of 'maintainer', and new ideas and implementations can grow from that basis.

[lourot]

although in this repo I have plenty of profile requests that resulted in a commit. I used to make these commits manually and link to the issue in the commit message. These people are users, not contributors. Do you agree with "just using is not contributing"? I wonder if my case is an edge case.

[jayvdb]

Well I suggest you create two repo, one for the software and another for profile requests.

That is what SaaS do.

[jayvdb]

Another way to deal with edge cases like that is ignore situations where the user has contributed only a small number of issues, or even exclude issues if the author is not also a committer.

The primary intent here is to better assess the relative effort of the core contributors to a repository. If that means they must have at least one commit, it only excludes a few important scenarios, like QA and PM type people who are not able to do Git. It is easy to tell most non-technical people that they need to do some docs commits for their issues to be considered.

[jayvdb]

although in this repo I have plenty of profile requests that resulted in a commit.

I've watched the few recent profile requests, and they are distinctly not what I am referring to.

When a PR uses Closes/Fixes #123, the issue is closed in a way that links the issue and PR in their metadata. Maybe you plan to do that in the future, but that isnt what you are currently doing, so the current workflow would not count as issues that resulted in a commit.

[lourot]

indeed I don't use this feature, I do just like #102 where the issue knows that it has been referenced by a commit, but the commit doesn't close the issue.

also I do nearly no PRs here, I push directly to master. I believe this is very common for projects not owned by companies.

[jayvdb]

I think you'll find almost every OSS org expects a Fixes/Closes references in PRs. And this is the target market for valuing issues, as it no longer a few ppl hacking away because it is fun. They need to attract new talent to avoid burnout, and old hands need to become community leaders who don't get to hack as much as they used to.