Labels for GitHub issues and pull requests about chapel HOT 48 CLOSED

I think we probably need 'docs' and/or 'spec' labels.

from chapel.

As far as formatting goes, it seems clearer to me to have the prefix letter be separated from the label via ": " rather than "-". The latter suggests to me that it's somehow part of the label itself. The former makes it look more clearly like a prefix.

This didn't occur to me in the meeting discussion, but if we could come up with a short form for each of the category (~4-letter word or clear abbreviation), I'd be tempted to use them rather than single-letter labels. E.g., "Area: " and "Stat: " seem less arbitrary/encoded to me (this is my main gripe about the labels -- I don't think the single-letter forms are at all intuitive and raise as many questions as they provide benefits. I have a feeling that even as a developer, I'd quickly forget what I or E stood for in the above scheme).

With respect to the specific proposals: I'd be tempted to keep "easy" and "steal" in uncategorized as they don't seem obviously related to me. If we added some sort of medium, hard, ... levels later then I'd introduce a "L: " or "Lvl: " or "Level: " prefix (but I remain against doing that on day one, as I think it's hard to be very specific after "easy" with minimal benefits).

Rather than "Importance" I'd use "T[ype]: "

from chapel.

Tried switching to the symbolic prefix notation, and realized that the labels are sorted only by the alphanumeric characters, ignoring spaces & symbols. So this is not a viable option.

edit: will update the labels to style 1 from above: type: Bug. If we are collectively unsatisfied with this approach we can continue this discussion

from chapel.

just "bug" "feature request" etc

from chapel.

As siblings to 'compiler', 'runtime', etc. should we add:

• makefiles
• docs

from chapel.

Suggestion:

Identifying parts of the code

• compiler
• runtime
• modules
• third-party (thanks @sungeunchoi)
• util (test infrastructure?)

from chapel.

I would suggest some way to label the difficulty of a given issue, like:

• easy/low ramp up
• medium
• hard/experienced dev only

from chapel.

What about 'external dependency` for bugs that are cause by third party libraries?

from chapel.

For PRs:

• post release
• waiting on contributor
• work in progress

I'd consider adding labels to indicate when something is ready-to-merged according to the author and when something has been reviewed.

For issues:

• I like the idea of identifying parts of the code

• I like the idea of identifying difficulty

• Besides the above, I'd like to identify issues in a way that tracks future categories:

  • bug
  • error message
  • feature request
  • multilocale (but maybe we should drop this one)
  • performance
  • semantic
  • unimplemented feature

• I'm not sure that these labels are useful to us:

  • help wanted
  • invalid

from chapel.

@sungeunchoi : I'd prefer two separate labels: third-party (for Chapel-bundled things in the actual third-party/ directory) and interoperability (for anything extern-related).

from chapel.

I think it'd be nice to have a "steal" label so that an issue can be given a default owner, yet also be flagged as a case of "take it if you want it!"

I agree with Michael about having tags per each 'future' category.

I like the idea of having an "easy" difficulty level. I'm not sure if "medium" or "hard add much additional value. If something's not easy, I typically wouldn't know how hard it was until I did it. Plus, I think the main benefit of these tags is to give a newbie a way to find things they might want to tackle.

from chapel.

w.r.t. labels and colors, it occurs to me that (if they're available), having gradations of a color for a given "axis" (say bug vs. feature request vs. error message vs. ... future) would probably be easier to learn to visually parse than using distinct colors. I.e., I might represent the axis above as "gradations of red or blue" rather than "bug = red, feature request = blue, etc.". Ditto compiler, third-party, runtime, etc. (i.e., they'd have gradations of a different color than the previous "type of future" axis).

If fine gradations of color aren't supported (I can't remember where to find them), it could still be that using the same color for all entries in a category (red for type of future; blue for code type) or related colors (reds and oranges for future types; blue for code type) would be a compromise.

from chapel.

The trouble with gradation is that it might make things more difficult for color-blind users. If we were going to rely on the colors meaning something, I think we'd want to shift the shades so that they would appear distinct in that case (i.e. use only darker shades of green and lighter shades of red, or something along those lines. Keep in mind that I'm not colorblind and so should not be considered the authority on what would actually help here, we should ask someone who is).

from chapel.

I'm not colorblind either, but I'd tend to think that colorblind users would tend to rely on the words more than the colors anyway? (e.g., as I understand it, many see red and green the same, so it's not clear we can pick any scheme that is going to be deeply meaningful for such people, esp. given the large number of labels proposed?)

from chapel.

That may very well be true, but I think we need to ask someone that is colorblind before making a decision like that, in case what we think would be "not a major issue" actually does make things unreadable.

from chapel.

My point is: By your argument, don't we need to ask someone no matter what color scheme we follow, if we use colors at all? I.e., I don't think the gradations are any different than color selections themselves. Has this been noted as a concern with existing color selections? Can we pick colors and open up an "are you color blind? Could our colors be improved?" issue rather than making this a blocking factor to setting up labels?

from chapel.

I would be satisfied with picking colors and opening an "are you colorblind, could our colors be improved" issue

from chapel.

(and would be happy to open the colorblind issue myself)

from chapel.

FWIW, I haven't seen the gradation color scheme applied for any other projects on GitHub. The color-per-broad-category approach seems to be the trending convention.

Once we have a color scheme agreed upon, we can start creating some of the labels suggested here (or start creating them now, and modify them later).

I can start creating suggested labels from this discussion, and we can add colors to them, when this is decided.

from chapel.

interoperability (for anything extern-related).

@benharsh - I'd suggest calling this 'external-deps', so that it's not mistaken for a C-interoperability label.

from chapel.

I think creating the labels sooner (at least, the obvious ones) would be great. I keep wanting to apply them, but...

from chapel.

@mppf & @bradcray - For future categories, how do we want to format it?

Some ideas:

• "future - bug"
• "f - bug"
• "bug"
  • (where futures are associated with each other by color scheme)

from chapel.

For color scheme:

@ronawho pointed me to Rust's Issue policy. I'd be in favor of adopting something similar.

from chapel.

@mppf Should "unimplemented feature" & "feature request" replace "enhancement" (essentially feature request)?

from chapel.

I think the traditional difference between these has been:

"feature request": Chapel doesn't do this and I think it should -- please consider making it do so
"unimplemented feature": Chapel claims it should do this (in the spec or docs) yet it doesn't yet

from chapel.

@ben-albrecht - I'd like the issue names to match exactly the future descriptions. I'm open to changing both but don't think we should aim to do that right now.

from chapel.

Recapping a discussion outside of this issue, label prefixes:

• allow easier sorting of labels by category
• eliminate the need for color to identify category

Here are some proposed label prefixes, categorizes the existing labels as well:

• Area of the project, e.g. Area: docs

  • docs
  • makefiles
  • compiler
  • modules
  • runtime
  • third-party
  • spec
  • util
    • (still need to decide new name for this)

• Type of issue, e.g. Type: feature request

  • feature request
  • bug
  • duplicate
  • error message
  • performance
  • semantic
  • unimplemented feature
  • question
    • (possibly remove)

• Stat[us] of issue, e.g. Stat: work in progress

  • work in progress
  • waiting on contributor
  • wontfix

• Uncategorized

  • post release
    • (possibly remove)
    • It would be ideal to correlate timelines to PRs & issues via milestones rather than labels
  • easy
  • steal
    • Possibly rename to help-wanted?

Note: Many of these categories are based on Rust labels

from chapel.

@bradcray Thanks for the feedback. I have updated my comment above to reflect your suggestions.

The hyphen style was adopted from Rust's issues. I agree that colon is clearer.

~4-letter prefix codes sounds good. If we find it too lengthy, or not worth the clarity, we can always convert to a shorter prefix.

Type works, especially when it's a 4-letter word.

from chapel.

I've changed our labels to adopt what is proposed above. Unfortunately, the 4-letter prefixes make the contents of the labels a little bit harder to parse, especially when there are several concatenated labels.

Here are some demonstrations of alternate approaches:

• type: Bug

• type: BUG

• TYPE: bug

• T: bug

from chapel.

I like the first two best in that they are self-descriptive and emphasize the more important part (the label rather than its category). I don't have a strong preference between them at present.

I think approach 3 emphasizes the wrong thing (my eye is drawn to the category) and I'm not convinced that the modest space savings in approach 4 justifies the lack of clarity.

from chapel.

I like 1 and 4. I didn't think I'd like the single-letter categories, but when looking at the screen shot, they seem OK. The 'category' part seems actually more useful when labelling an issue/PR than when looking at issues/PRs.

from chapel.

I agree with that comment -- this was what made me ask whether one could curate the order in which their labels showed up in the list when selecting them, as I think the category only significantly helps at that point.

from chapel.

Maybe we can sort them by varying the number of spaces at the front of each label. Crazy, but could work...

from chapel.

If that caused them to sort properly and didn't look too weird, I could get behind it. This also makes me realize that we could use some other characters than letters/words for the categories like "+", ">", "#", etc. A little goofy arguably, but maybe less distracting than the previous proposals (again, if spaces didn't work).

What controls the order in which labels are displayed on an issue? Alphabetically? Is there an order we'd like the labels to appear in? (e.g., type first and then area?)

Ah... optimizing labels... :)

from chapel.

@mppf - I liked the idea, but unfortunately GitHub strips the label strings.

@bradcray - This is where my mind went as well. I tried it out, and it doesn't look too bad IMO:

from chapel.

I kinda like this best (though I'm still open to the options 1 and 2 above as well). Nice job on picking a natural label for @ and for getting the sorting proper. I feel neutral about '-' -- neither particularly excited by it nor offended by it.

from chapel.

In this instance, I prefer the brevity & parsability over clarity of the label prefixes, so I'd prefer the symbols or single character (4 above).

Of course, these labels will be explained in a doc somewhere.

from chapel.

Should we add a GSoC (ramp-up project) label? Or just assume that easy means that or that people will find things on their own?

from chapel.

Personally, I don't think we should add a GSoC label. I don't think we want to imply that easy tasks should only be worked on by GSoC people, and conversely, I don't think we want to distinguish GSoC work from other work for us, as part of the point is to generate interest in long-term contributions that continue to occur after GSoC has finished.

from chapel.

Regarding some of @mppf 's recent uses of the "steal" label... I'd think that "steal" should only be applied if there is an assignee on a given issue (and that person would be happy for someone to take it from them). I'm assuming that if there's no assignee, it's automatically up for grabs (i.e., effectivey it's stealable except that there's nobody to steal it from).

from chapel.

To the GSoC label suggestion, I'd say it's a question of whether we want to distinguish "easy for core-developers" from "ideal ramp-up task for new developers". In either case, I don't think we need to make a GSoC-specific label, as we could still point GSoC students to the label intended for them.

On the "steal" label usage, I agree with your proposition.

from chapel.

It's also a good way to indicate who to ask for guidance on completing the task

from chapel.

Additional suggestions inspired by a discussion with @ronawho:

• split area: Modules into:
  • area: Internal-Modules
  • area: Standard-Modules
  • area: Package-Modules.
• new: area: Tools
• new: area: Test-Suite
  • Focused on tests themselves, rather than testing infrastructure, which are covered in area: BTR
• new: area: Chplenv
  • Since printchplenv and it's underlying Python modules (util/chplenv/) are components of the Chapel compiler, I think it will be useful to distinguish them from area: Compiler and area: BTR.

Also, I wonder if we should distinguish feature requests and unimplemented features from language modification proposals, e.g. #5066

from chapel.

I feel nervous about having too many labels (from the "time it takes to select them" perspective") and feel nervous about the Modules split as a result. If it were split at all, I'd probably keep it to just internal and standard where standard would cover packages, layouts, distributions, etc. If we did split them, I'd put modules before internal/standard/whatever so that they show up adjacently in the list.

(Fear of too many labels was also the reason I suggested having a broad "design" or "language design" label rather than the more specific "semantic", "syntax", etc. labels)

Chplenv similarly seems too specific for me and I feel as though there should be some single label that covers Makefiles, scripting, util, etc.

On email Mike suggested that trying to optimize for "which labels" before having a ballpark notion of "how many labels" might be putting the cart before the horse. I suppose a max of 10-12 labels per category seems like about the limit to me, where 5-6 seems much better.

from chapel.

I found myself wanting a "chpldoc" label as a way of distinguishing that the bug was chpldoc specific. Would we want a similar label for chpl-ipe? Or chplvis?

from chapel.

After the recent discussion, we have made the following changes:

General

• Removed post release label, and will be using milestones instead

Type Labels

• type: Semantic -> type: Design
• type: Semantic -> type: Design

Area Labels

• area: Spec -> area: Language
• New: area: Tools
• New: area: Tests

Status Labels

• type: Duplicate -> stat: Duplicate
• New: stat: Needs Design Review
• New: stat: Needs Code Review
• New: stat: Needs Testing
• New: stat: Ready to Merge
  • (for when a PR is ready to merge, but is holding off on merging for a variety of possible reasons)

This concludes #4946. Any further discussion on adding, removing, or modifying the existing labels can take place on an individual issue basis.

from chapel.

We very specifically steered away from labels related to priority (e.g., "important" or "not important") and I continue to think that that was an appropriate decision, but as time has passed, I find myself wondering if we should have a "gating issue" label, particularly for user issues. Specifically, I often find myself wondering whether issues filed by GSoC developers or user-developers like Nikhil are holding them back, or whether they're just being great citizens and filing them as they go but have found a workaround or are not being held back by them.

from chapel.

@bradcray - I agree that this is a problem. I wonder if user issue would have separate value from gating issue or if we should just transition user issue -> gating issue, where we get some kind of confirmation from the user that the issue is blocking them before, before adding the label.

Logistically, this idea may gain more traction as a new issue, rather than as a comment in this closed issue. The intention was for future label proposals to take place in individual issues, since this issue got a little crazy :)

from chapel.