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