On Thu, Jan 17, 2019 at 07:17:30PM +0100, Patrick Storz wrote:
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.
And don't forget that bugs can be moved both ways - if someone tries to sneak in a poor bug report into an internal tracker, someone can just bump it to Inbox.
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).
Yes, a triager group makes sense. We probably should have a developer group as well to go with it. I'll have to study gitlab permissions more thoroughly so this can be set up properly.
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:
- Add them as "Reporters" for the top level Inkscape project ([2])
- Create a "bug team" group below the top level and assign it to all repos it should have access to
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.
I agree the second approach would be cleaner. I'd love to move away from adding new folks at the top level, because while that's convenient, it prevents us from establishing better access control for places we need it.
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!).
Yes, completely agreed. I like that this scheme allows an extremely liberal policy for gaining rights within Inbox.
Bryce