Hi Maren,

answering below on the preceding four messages by you ;-)


Am 17.01.2019 um 16:56 schrieb Maren Hachmann:
Are tags ported from one tracker to the other when moving a bug?
Do we need them to be group-wide for that to work?

I'm not sure if this is a technical question (then the answer is likely yes, but I'm not 100% sure) but I'd actually say this is a feature we don't even need.

One of the advantages of having subproject trackers is that the teams involved with each subproject can decide which tags are required and most useful.

Also needed tags will vary (e.g. the inbox will likely have tags like "need more info" or "question") whereas those hopefully will become a thing of the past in the subproject trackers where we need tags for technical details that only developers in those subprojects will understand and be able to assign.

Maybe a few group-wide labels might make sense in the long run, but I'd say we should keep it to a minimum and they should be really well though out and only be used for tracking of topics that involve multiple subprojects. ("translations" might be one such tag).


Who is supposed to watch for duplicates now?
- Users?
- Triagers?
- Developers?

All of them ;-)

[1] https://gitlab.com/groups/inkscape/-/issues


Am 17.01.2019 um 17:18 schrieb Maren Hachmann:
Will access to the developer-facing bug tracker be restricted?

If not, how are you going to ensure that users do not circumvent the new
system in the hopes of getting their pet bug tackled faster?

I'd keep it open and wait to see how things actually turn out.

There's no point in keeping experienced people from filing bugs directly and restricting access will be a maintenance burden as we'd have a lot of work on our hands to hand out individual access rights.

What we should restrict are things like labels (people tended to put as many tags as possible on their bugs in Launchpad because they thought it would make them easier to find, when actually  the opposite was true, and many of the applied labels by non-triagers were usually wrong)

We should probably form a "bug team" like we had on Launchpad with extended access rights, that experienced triagers can join and that has access to all trackers. (I guess reporter rights might be most suitable for this group which we can hand out rather freely to everybody who has showed some common sense in bug triaging work).


Am 17.01.2019 um 17:46 schrieb Maren Hachmann:
Sorry, another one:

Please ensure that it's allowed for people to request membership in the
new inbox subproject (if that isn't allowed yet, I cannot test).

This is where new triagers would apply for the team to offer their help,
I think?

No idea which permissions they would need for moving a bug to the other
tracker, though.


As already suggested above I think trusted triagers should have global "Reporter" rights.

We can achieve this in two ways:

The second option is likely cleaner (the top level project is already flooded with members with no easy way to track who joined why) but requires a tiny bit more maintenance effort to create the team and keep track of it. Likely Bryce should comment on which way he'd prefer.

As for the "inbox" itself we can probably hand out access rights for almost anybody who asks for them (might be a good way to weakly bind potential triagers in an early stage with close to no implications for the project as a whole) but everybody should be aware that those rights won't really allow anything but handling bugs in the inbox itself (as an example I think at least reporter rights in *both* projects are required to move a bug, so trusted triagers need them!).

[2] https://gitlab.com/inkscape/


Cheers
Patrick