| Re: [escet-dev] GitLab |
|
> I am not a fan of longer labels.
I agree long labels are not ideal, so let's not do that.
> Colors work better.
I tried to change the colors a bit. We have quite some component labels, so just shades of blue won't work. I used shades of blue for Chi/CIF (modeling languages), purple shades for Common/Products/RelEng
(support components), orange/brown for SeText/ToolDef (support languages), and changed 'Help Wanted' to grey. I think we now have quite distinct colors for each of them.
> Another option is to have a single letter prefix, eg "cChi" just as effective,
and much less long 🙂
Seems a bit unreadable for anyone who doesn't know
what the 'c' prefix stands for. I propose to leave the names, and see whether the current order even bothers us.
>> I 'starred' all the labels. This allowed me to define an order [...]
> [...] wait until we have a decent set
of problems first 🙂
Agreed.
>>
Not sure what to add to my 'test' issue (#2). Nothing...?
> Isn't that just our issue system that
is working?
I guess so indeed.
Dennis
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, A.T. <A.T.Hofkamp@xxxxxx>
Verzonden: donderdag 22 oktober 2020 07:39 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] GitLab
> I did the following:
Thanks.
> We can rename 'Chi' etc to 'Component Chi' etc. That will improve the ordering when adding/displaying labels. What do you think?
I am not a fan of longer labels. Colors work better. For another project I picked distinct color for each type of labels, and then different shades of that color for each label within the type.
Another option is to have a single letter prefix, eg "cChi" just as effective, and much less long
🙂
> I 'starred' all the labels. This allowed me to define an order: first bug/enhancement, then component labels, finally 'help wanted'.
Isn't this about the order of the issues in the list? Not sure though. Anyway, wait until we have a decent set of problems first
🙂
> Not sure what to add to my 'test' issue (#2). Nothing...?
Isn't that just our issue system that is working? The issue is not relevant for the project, so you have no labels. You can attach such an issue to a milestone nonetheless, if you want to fix such a problem, imho.
Albert
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Wednesday, October 21, 2020 19:13 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] GitLab
OK, then I think we're in agreement now.
I did the following:
Not sure what to add to my 'test' issue (#2). Nothing...?
We can rename 'Chi' etc to 'Component Chi' etc. That will improve the ordering when adding/displaying labels. What do you think? Will be significantly longer, especially if we have many labels, e.g. for issue #1.
Dennis
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, A.T. <A.T.Hofkamp@xxxxxx>
Verzonden: woensdag 21 oktober 2020 12:14 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] GitLab
Initial contribution would be "all" rather than "other" indeed.
Let's drop "other" for now, if we run into a valid use-case it can be added.
"feature request" also seems something that's not clear enough what it means relative to enhancement.
Let's drop that too, and wait for a valid usecase 🙂
Albert
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Wednesday, October 21, 2020 09:35 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] GitLab
>> Maybe we do also need an 'other', in case nothing fits, and we do want to explicitly label it.
I was thinking about how to label issue #1 (Initial contribution). Would that be 'other', or would it be labelled with all the other component
labels, or would it be labeled with all component labels including 'other'?
It concerns all the various components, so labeling it will all the components feels right to me. Then maybe it doesn't need 'other', as
we will only use that if none of the other component labels is attached?
>> Regarding 'feature request' [...]
> [...]
> To me, an enhancement is something we'd like to have. (It fits in the road-map, and we may want to spend time on it.)
> [...]
> "FutureExtension" tag may also work.
I'd prefer to keep 'what it is', e.g. a 'bug' or 'enhancement' separate from planning (roadmap, etc). In that sense either something is
broken (bug) or we want something more/better/different (enhancement). I'm still not sure what is the difference between 'enchancement' and 'feature request'. In a feature request you also ask for an enhancement, right? You want that feature, which is not
present, and it would enhance the toolset if the feature were to be present.
If we don't want to spend time on an 'enhancement', or don't have the time to spend, we can add the 'help wanted' label to signal that.
It would be orthogonal, 'what' vs 'who'.
> "he, consider making a release for <random-container-tool>",
> "he, we ran our tool and found the following list of things: <dump of the tool output>"
> "he, make CIF compatible to <random-other-verifier/simulator/code-generator/...-tool>"
IMHO supporting another tool and adding compatibility sound like requested enhancements, and would fit the 'enhancement' label. Whether we want it or not, can be discussed in the
issue. If it is deemed a bad idea or for some other reason it is not in scope or for some reason can't/won't be done, we can close the issue.
The 'found the following list of things' could be bugs if it is actually broken, or could be enhancements of the code in case they are e.g. code style things. It really depends on the 'things'.
I guess I find the difference between 'feature request' and 'enhancement' too vague, or maybe I don't understand it enough yet. If there is a clear difference, I don't mind adding 'feature request', but I don't see the value yet.
I think whether to add 'feature request' is the only discussion topic that is unresolved at this point.
> If the work-flow doesn't work, we can always add more labels.
Agreed.
Dennis
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, A.T. <A.T.Hofkamp@xxxxxx>
Verzonden: woensdag 21 oktober 2020 07:35 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] GitLab
> Maybe we do also need an 'other', in case nothing fits, and we do want to explicitly label it.
I agree to have that, even if we never need it. It makes it always possible to label an issue with a component, so we can find issues that have no component.
> Only 'bug' may be easier, as everything else is an 'enhancement'?
Bugs are agreed I think.
To me, an enhancement is something we'd like to have. (It fits in the road-map, and we may want to spend time on it.)
However, at other open source projects I worked in, users typically add issues describing their ideas. At Github we also get what
I conisder to be issue-spam. People promoting their tool or product over a large number of projects:
They are not a bug, and to me, not always immediately an enhancement. For these things I added feature-request, stuff that is not a bug, it's not on our immediate path, and we don't have it currently. "FutureExtension" tag may also work.
> 'Confirmed' is that ... . 'Reproducible' .... . Not sure whether we need this. Can't we just discuss it in the comments?
If you pick bugs to include for a release, it's nice if you can see in the list whether it needs triage.
However, it's indeed perhaps too much work to keep track of that. I agree with your idea, let's remove these states, and then try things for a while to see how it works out. If the work-flow doesn't work, we can always add more labels.
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Tuesday, October 20, 2020 12:43 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] GitLab
> Got lost in ESCET group instead of the project (why do different things have the same name??!!), which has an empty set of labels.
Indeed as Eclipse project we have a group. It currently contains one project, with one repository.
>>> Regarding 'issue tags'. [...]
Limiting a wild-growth of labels seems practical. For me labels are only useful if they serve a purpose.
[component labels]
I like the 'chi', 'cif' etc labels. It can be used filter based on these 'sub-component' labels. I propose the following ones: chi, cif, common, products, releng, setext, tooldef. This to match the repository structure. I think we should also label with 'cif',
as a label indicates we thought about it and it is indeed CIF related. Also, I wouldn't want to make assumptions about what will have more or less issues. Without a label we don't know whether it is 'cif' or not yet labeled, or no label fits.
Regarding 'release', I think that fits in 'releng' (release engineering).
Maybe we do also need an 'other', in case nothing fits, and we do want to explicitly label it.
[artefact labels]
I agree to remove 'documentation'. Documentation, code, tests, etc, all important. I think the 'chi', 'cif' etc is more useful.
[type of change labels]
For me 'bug' and 'enhancement' seem fine as well.
May be useful to divide into these 2 partitions to focus on bugs first, before new enhancements. May also be helpful when making a release changelog, which may be similarly categorized. Only
'bug' may be easier, as everything else is an 'enhancement'? However, again explicitly labelling may be better, similar to using 'cif' labels.
'Confirmed' is that someone other then the reporter has observed/confirmed the bug. 'Reproducible' means that it happens every time under certain conditions, e.g. not a sporadic multi-threading issue. Not
sure whether we need this. Can't we just discuss it in the comments?
Regarding 'feature request' I'm not sure. I would prefer people to
discuss feature requests on the dev-list or forum. If we agree it is a good idea, we'll create an issue, which can be labelled 'enhancement'. People will probably create feature requests, but I wouldn't want to promote that. It can just be labelled 'enhancement'
anyway, right? Either something is broken ('bug') or you want something more/different/better/etc ('enhancement').
Similarly, I don't think a 'general discussion/ideas about a topic'
issue is a good idea. That is what the dev-list (developers) and forum (community) are for. Let's try to keep the issue list clean, with only a small number of active issues. I wouldn't want to use epics for this. I would prefer to use epics for actual decided
work, if at all.
[community labels]
'community contribution' doesn't have any value for me. What would be its purpose? I propose to remove it.
'help wanted' may be useful if we think something is useful or nice to have, but have no time to address it ourselves. it makes it possible to make a filtered list of issues that the community can work on.
[planning/status labels]
I agree to remove 'high priority' and 'important'. Everything is important. We'll indeed schedule issues for a release when we make a release plan. We'll connect them to a milestone then. Priority labeling is also typically never kept up to date.
I agree to remove 'work in progress'. Assign someone/yourself to make it work in progress. Issues without an assignee are not in currently in progress (no one is currently working on them). Seems simpler. We can indeed create multiple milestones, e.g. '0.1
+ 1', '0.1 + 2' etc for future releases, until we know the actual number.
[summary]
Changes that I propose, as summary of the above:
Dennis
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, A.T. <A.T.Hofkamp@xxxxxx>
Verzonden: dinsdag 20 oktober 2020 10:33 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] GitLab
> Regarding 'issue tags'. We already have a number of predefined 'issue labels' as GitLab calls them. See
https://gitlab.eclipse.org/eclipse/escet/escet/-/labels. Do we see the need for other labels?
Got lost in ESCET group instead of the project (why do different things have the same name??!!), which has an empty set of labels.
Looking at the list above, I am not too impressed by it.
"Bug" and "Enhancement" seem fine.
"Community Contribution" and "Help Wanted" I can live with, although not sure of the use.
"Confirmed" seems like a useful thing at least for bugs, not sure if we'd ever use that for anything else.
There is also the notion "Reproducable" for bugs, not sure if "Confirmed" includes that.
"High Priority" and "important" are equivalent as far as I can see. Either has questionable use I think, when is a bug not important or low priority?
"work in progress" seems a bit fuzzy, are there issues which are not work in progress? The ultimate goal is to have an empty list of issues, I think.
"documentation" seems off, it may come from the idea that documentation is weird or not important or so, which is not how we work. At least to me code and documentation are equally important at least (and perhaps docs are even more important!)
------
So, I would propose to keep Bug and Enhancement. We may also want a FeatureRequest for all the "please implement X" issues.
The only other kind of issues I can think of are "Release" issues and "general discussion/ideas about a topic" things.
The former needs a somewhat more generic name perhaps, for all "work needed which is not a bug or enhancement" since we make an issue for everything (not only release, but also build infra-structure, CI, website/etc, ie "other"
🙂 ). The "general discussions/ideas" can fit in the Epic thing.
"Community Contribution", "Help wanted", and "Confirmed" seem fine, where the latter should probably imply "reproducable"
For "High Priority" or "important" I see no use, possibly also due to the next item.
"work in progress" I propose to drop. Instead make a milestone "future", and attach everything that we deem worthy of doing at some point.
Also, make a milestone for the next release (or even just "next-release" if we don't have a number) for things we want to actually work on.
My guess is that we are well aware of what is important, so having labels for it isn't useful imho.
"documentation" shouldn't be treated as special imho, I propose to drop it. code and docs are equally important, they go hand-in-hand.
We may want to add a few labels for the parts, ie "common", "cif", "chi", "tooldef", "setext". This is not complete, eg build related things are missing. Also, "cif" may be not too useful, as most issues will have that so it can be a default by not labeling
it.
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Monday, October 19, 2020 15:58 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] GitLab
Hi all,
Regarding 'issue tags'. We already have a number of predefined 'issue labels' as GitLab calls them. See
https://gitlab.eclipse.org/eclipse/escet/escet/-/labels. Do we see the need for other labels?
I propose to start with what we're given. Should we need another label, we can start a separate discussion about that label and add it if we agree it is valuable.
Dennis
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Verzonden: maandag 19 oktober 2020 13:02 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: [escet-dev] GitLab
Hi all,
In another discussion, Albert mentioned:
> [...] should we discuss gitlab configuration?
> Issue tags and milestones at least I think, and probably branch usage/names/conventions?
> [...]
> In general, I think less is more here.
I suggest the following for milestones:
We have both epics and milestones. Both seem to group issues. Epics seem to be meant to group by functionality while milestones seem more focussed on what you address/finish/release
together. You could thus have funcionality in an epic that you release partly as part of one milestone and the rest as part of a next milestone. Maybe if we later have releases with multiple topics (groups of functionality) epics may become handy as well.
I suggest the following for issues:
For commits:
These are my first thoughts. Let me know what you think about them and whether you have other ideas.
Dennis
|