owncloud/core we had several labels like 1 - to develop, sev1 - high, … .
Will we introduce the same labels in Nextcloud, or do we do it different
Labels are a good idea. However, we shouldn’t get too specific. I’m thinking the following labels, with one type being main and the others being essentially comments on it. For example:
- Needs work
- Feedback requested
- Needs rebased
- Needs squashed
I like the idea of
1 to develop,
2 developing and so on. But maybe some documentation is needed about the labels.
In ownCloud there are labels like
Looks like those are of some internal ticketing system. Would be good if that’s documented.
I have always thought that these are customer requests and issues from the enterprise edition I don’t know if we need them with the new “openness” of Nextcloud
Yes. Can’t go into more details though. Sorry.
Definitely not. Even internally there was always a huge confusion about “what color means what”, especially as color meanings even changed etc…
There will be a way required for Nextcloud GmbH to track issues from customers but we will be more transparent about it and not add magic labels to hide the fact.
As a sidenote to issues from customers. Gitlab creates issues for customer requests, but simply links to their internal ticketsystem or the internal customer profile to make this connection for support staff easier. But the actual issues and their discussions are public even for their EE.
I would also like to get these labels on here simply because they reflect the state of a PR so every one can filter for PRs which are ready to review, test, etc.
I also already though about the labels and how we could improve stuff compared to what we had until now.
I come up with following categories:
- Describe the issue type – this label should always be there
- bug OR
- Importance of the issue
- What is affected:
- State of the issue
- needs info
- 1 to develop
- 2 developing
- 3 to review
- 4 to release
“new contributor” label for pull requests
This should be applied to every PR created by a user who is not part of the Nextcloud GitHub organisation. This way we can identify new contributors easily and make sure to help them in time to get their pull request merged, and in generally help them to get used to the development community.
Some special labels
- starter issue (can be combined with all the types above and indicate that this is a good issue to work on for someone who just want to get started with Nextcloud development)
- design (for design and UX issues/enhancements, as we had before)
These are issue labels, but what about pull requests? In another thread it was brought up that you should have an easy way to look at PR from a core dev versus a PR from random_community_member_01.
Good point, I missed this one in my collection. Therefore I would suggest a label like “new contributor” which is added automatically to every PR not created by a contributor who is already part of the Nextcloud organisation at GitHub. This way we can identify new contributors easily, try to react in time and help them to get their stuff in.
Neat way to solve the “new contributor” label!
Labels that might make sense would be the ones mentioned by @jyaworski to find issues that
- Needs info
- Needs work (e.g. review to be incorporated)
I would also be fine with a “customer” label (formerly the blue-ticket?) since I usually also targeted these issues since resolving these is viable to the company behind the software to some extend.
good point, added “need info” to my list
in the past we just set it back to “developing” if we noticed during review that larger changes are needed. I think that worked quite well
yes, we probably need something like this. And I agree that it is better to have a label with a clear, descriptives name instead of “blue tickets” and similar stuff. But I would really try to start out with a minimal set of labels. We will probably need to add some over time. But let’s add them when we need it.
True, simply labeling it as “developing” does the job
Yeah, let’s keep it simple for starters and see where it leads us
please add labels for “junior Developers” or/and “Student Jobs” … so that people with less experience also have an opportunity to contribute for the project.
Also, it would be good to use the same labels across all repositories.
the client and core repos, for instance, do not use exactly the same labels in ownCloud.
edit : I don’t mean that there can’t be specific labels for each repository, but at least generic stuff @bjoern described, the same labels should be used.
makes sense, even though for the “feature::” this might not work in all cases but that should be negligable.
based on my proposal I created the labels for the server repository. I will try to come up with a script to sync them over to the other repositories (of course beside the "feature: " labels)
feature: dav or should we create separate
app: "appname" labels like in
Thanks for creating the label… I would just use for every app/feature “feature: name”, no need to make the arbitrary distinction. Some features are also implemented partially as a app and partially in core. For example encryption and the encryption modules or sharing and the share providers.
@bjoern can we get your proposed general labels for the Android project please and could you also create a label “approved” which we will you to flag issues that are approved for development? That would be great