Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Candidate Release Comments (Issues Closed) #188

Open
GeorgLink opened this issue Jun 22, 2019 · 8 comments

Comments

Projects
None yet
5 participants
@GeorgLink
Copy link
Member

commented Jun 22, 2019

This issue was created to collect comments about the upcoming metrics release.

This thread is for comments about Issues Closed

GitHub location: https://github.com/chaoss/wg-evolution/blob/master/metrics/Issues_Closed.md

Release candidate: https://chaoss.community/metric-issues-closed

See all release candidates of metrics are at:
https://chaoss.community/metrics-rc/

Important Dates

Release Freeze: June 21st, 2019
Candidate Release: June 24th, 2019
Comments Close: July 24th, 2019
Release Date: August 1st, 2019

@klumb

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

Dead link (Issues are defined as in Issues.) at line 8.

Not sure if this should go to "Issues New"

if so will need an absolute URL path

@jgbarah

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2019

Yes, this should be Issues New.

@sgoggins

This comment has been minimized.

Copy link
Member

commented Jul 4, 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:

  1. Linked to Commit/PR # (most commonly, I think, these will be linked to specific bug fixes.)
  2. Unknown (Probably the most common case)
  3. Unrelated to a specific commit/PR # (Possibly primarily useful for issues that result in a series of commits/PRs to implement a new feature)

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

@sgoggins

This comment has been minimized.

Copy link
Member

commented Jul 4, 2019

Based on @klumb and @jgbarah comments above mine, I am unsure if I commented in the right place. :)

My intent is to comment on issues:closed.

@jgbarah

This comment has been minimized.

Copy link
Collaborator

commented Jul 9, 2019

Based on @klumb and @jgbarah comments above mine, I am unsure if I commented in the right place. :)

My intent is to comment on issues:closed.

I think this is the right place to comment on the Issues Closed metric ;-)

@jgbarah

This comment has been minimized.

Copy link
Collaborator

commented Jul 9, 2019

[...]
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:

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?

@foundjem

This comment has been minimized.

Copy link
Collaborator

commented Jul 9, 2019

In some communities, source code and documentation are treated with the same level of importance.

@jgbarah

This comment has been minimized.

Copy link
Collaborator

commented Jul 10, 2019

In some communities, source code and documentation are treated with the same level of importance.

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 ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.