Re: Inkscape's Inbox (gitlab "friendly feedback" tracker)

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

  * User should likely search  [1] for issues (It will be an unsorted
    mess, but how should an average user know where to do a more
    specific search? It's the best we got and basically status-quo on
    Launchpad).
  * Triagers should always search the subproject trackers before moving
    a bug there.
  * Developers of the respective suprojects will be most likely to
    remember existing bugs by heart and have yet another chance to close
    moved bugs when both the reporter's as well as the triager's search
    didn't turn up the duplicate.

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

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

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

_______________________________________________
Inkscape-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel