| ... | @@ -141,6 +141,25 @@ It might also be necessary to also search the pull-request queue on Github, in c |
... | @@ -141,6 +141,25 @@ It might also be necessary to also search the pull-request queue on Github, in c |
|
|
|
|
|
|
|
> "The ability to apply multiple labels/tags, to indicate which components an issue relates to, provides a more flexible classification system than having to create an issue in one of a number of projects." (@davej)
|
|
> "The ability to apply multiple labels/tags, to indicate which components an issue relates to, provides a more flexible classification system than having to create an issue in one of a number of projects." (@davej)
|
|
|
|
|
|
|
|
|
This seems to be one of the issues that has been raising a lot of concerns. It does require more clarification.
|
|
|
|
|
|
|
|
So far, ~~quick~~ recap:
|
|
|
|
|
|
|
|
* Subprojects can share labels, and we can search issues across subprojects
|
|
|
|
* We could have a special process to triage new issues, such as having a front-end form.
|
|
|
|
* Although we need the reporter to have a Gitlab account in order to receive the responses.
|
|
|
|
* It might be better to focus on having a very clear signup process.
|
|
|
|
* Spam management is also an issue.
|
|
|
|
* Some issues might span multiple subprojects (ex: bug in a token included in a contribution receipt for an event).
|
|
|
|
* Seems OK for triage folks to move the issue to the appropriate subproject.
|
|
|
|
* It doesn't seem to be like a major problem. If critical, it will be labelled as such. We could have a policy to "default to core" when it's not really clear.
|
|
|
|
* What do we gain from splitting the projects?
|
|
|
|
* It helps more clearly identify who are the primary leads for a specific area. We have been talking about having a google-doc with "people to ping for PR-review".
|
|
|
|
* Example: translation, civicase, grant, taxes, accounting/financial, etc.
|
|
|
|
* We might not want to be very aggressive about splitting either. Only where it makes sense.
|
|
|
|
* They may want to have their own wiki space (draft docs, roadmap/planning)
|
|
|
|
* While we can do part of this with labels, having subprojects makes it possible to have more granular labels. Ex: taxes have different challenges for Canada (HST/GST per province) than for VAT in Europe. Having a single "taxes" label would be limiting.
|
|
|
|
|
|
|
## Document the account creation, permissions, workflow
|
|
## Document the account creation, permissions, workflow
|
|
|
|
|
|
|
|
> "Can a non existing user easily create an account and (issue) report?" (@xavier)
|
|
> "Can a non existing user easily create an account and (issue) report?" (@xavier)
|
| ... | | ... | |
