Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Candidate Release Comments (Issues Closed) #188
This issue was created to collect comments about the upcoming metrics release.
This thread is for comments about Issues Closed
Release candidate: https://chaoss.community/metric-issues-closed
See all release candidates of metrics are at:
Release Freeze: June 21st, 2019
I think issues related to source code might be identifiable with a different metric. This varies widely in practice, with platforms like GitHub and GitLab supporting linking more organically... Yet I don't think the consistency of use is widespread.
So, with regards to this definition from the metric (below), my suggestion is that the default assumption that an issue is NOT linked to source code directly. We have not gotten to a level of detail where we define metric attributes (explicitly), but I think some indication of a "source code status" being specified would be appropriate. I think the status would have 3 states:
"Criteria for source code. Algorithm. Default: all issues are related to source code.
If we are focused on source code, we need a criteria for deciding whether an issues is related to the source code or not."
This is indeed the default assumption. What we wanted is to capture metrics related to source code, since this is defined in context of the Code Developement focus area. But since, as you suggest, knowing when an issue is related to source code is tricky (except when projects are labeling them themselves), we propose a parameter "Criteria for source code", which is "all issues are source code" by default. If an implementation in a given project can do it better, they could use a specific "Criteria for source code".
Is this more clear now?
Thanks, @foundjem, you are right. But I think this is not matter of importance. In any project, you may be interested in, for example, how issues for code are performing, and issues for documentation. Both may have different characteristics, and both may have for example, different typical time spans. Sin we're in the context of the "code development" focus area, metric should be referred to source code, as much as reasonably possible.
Of course, the area code could be ill-defined, and/or we may need another "documentation development" area code. But this is out of scope when discussing this metric, i think ;-)