Crystal: [Discuss] New issue tracker tags

Created on 10 Jan 2017 · 5Comments · Source: crystal-lang/crystal

Hey everyone! We are trying a new set of tags for the issue tracker, as you might have probably already noticed. We plan on gathering feedback for a few weeks and test how it fares, and adjust accordingly.

Please do share your thoughts here!

discussion

Source

spalladino

👍1

Most helpful comment

A few thoughts about the new labels and some more changes we might implement:

We should add a kind:refactor or more general kind:task, for those things that are not actually features (and certainly nor bugs neither questions). We know, it's not easy to classify things into buckets, and the balance between being inaccurate and having an unusable number of buckets is difficult to achieve.
An issue goes through different stages during its lifetime:
1- First, after being created, it must be accepted, meaning that we acknowledge the bug or accept that it is a feature we want to have in the language.
2- Afterwards, if the issue is not trivial, we need to agree on a design, on how to achieve that feature, or which API it would expose. This design might have been provided as part of the issue originally, in case of drafts.
3- Once we have a design we like, the issue is ready to be implemented, and the process follows in a PR.
We want for people arriving to the issue tracker to easily know how they can contribute. As such, a generic label community:help-wanted is unclear as what is needed in that particular issue without having to go through it. We might split this label into:
1- community:to-research, for issues where we need help investigating something
2- community:to-design, for issues already accepted where we need to define how it should be implemented
3- community:to-implement, for issues where a PR with the implementation is needed
A good practice would be to _batch_ certain related issues, until we reach a point where we want to tackle all of them together; these issues could be marked as deferred, delayed, batched, or whichever better name we come up with. We still got to decide what artifact we want to use for batching:
1- Another issue marked as an epic or similar, like #2665
2- A label, by refining the topics we currently have
3- A milestone, though we might want to use them later once we clean up the roadmap
4- A github project, where we can choose which issues of a topic will be tackled in the next, though it might be overkill

Thoughts?

spalladino on 18 Jan 2017

👍3

All 5 comments

When would status:implemented be used?

lbguilherme on 11 Jan 2017

When a issue is closed there might be lack of information whether it was effectively solved or not. Issue closed+status:implemented can be read as done. Other closing reason like duplicate or invalid exhibit that there where no action taken in the source code.

When a PR is merged there is already evidence that it is implemented so there is no need to apply the tag there.

bcardiff on 11 Jan 2017

👍1

A few thoughts about the new labels and some more changes we might implement:

We should add a kind:refactor or more general kind:task, for those things that are not actually features (and certainly nor bugs neither questions). We know, it's not easy to classify things into buckets, and the balance between being inaccurate and having an unusable number of buckets is difficult to achieve.
An issue goes through different stages during its lifetime:
1- First, after being created, it must be accepted, meaning that we acknowledge the bug or accept that it is a feature we want to have in the language.
2- Afterwards, if the issue is not trivial, we need to agree on a design, on how to achieve that feature, or which API it would expose. This design might have been provided as part of the issue originally, in case of drafts.
3- Once we have a design we like, the issue is ready to be implemented, and the process follows in a PR.
We want for people arriving to the issue tracker to easily know how they can contribute. As such, a generic label community:help-wanted is unclear as what is needed in that particular issue without having to go through it. We might split this label into:
1- community:to-research, for issues where we need help investigating something
2- community:to-design, for issues already accepted where we need to define how it should be implemented
3- community:to-implement, for issues where a PR with the implementation is needed
A good practice would be to _batch_ certain related issues, until we reach a point where we want to tackle all of them together; these issues could be marked as deferred, delayed, batched, or whichever better name we come up with. We still got to decide what artifact we want to use for batching:
1- Another issue marked as an epic or similar, like #2665
2- A label, by refining the topics we currently have
3- A milestone, though we might want to use them later once we clean up the roadmap
4- A github project, where we can choose which issues of a topic will be tackled in the next, though it might be overkill

Thoughts?

spalladino on 18 Jan 2017

👍3

@spalladino I think either "epic" issues or github projects are what I would use here. Although github projects may get a little messy unless we decide they must be structured in a specific way.