Hi Martin,

I would like to bring up the point of "bug workflow", which Launchpad tracks pretty nice, even with editing permissions for the average user.

The main routes are:

Successful bug report: New -> Confirmed -> (Patch attached) -> Fix committed -> Fix Released.

Report was okay, but didn't help: New -> Wontfix/Duplicate.

Low-quality report, user should resubmit in higher quality: New -> Invalid/Unreproducible/Incomplete [-> New]

I'm not sure how this should be handled in Gitlab. It can somehow be approximated via tags, such as in the link below, but there is no nice overview as on Launchpad. Compare Gitlab: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues?scope=all&so... with Launchpad: https://bugs.launchpad.net/inkscape/

Another point is the "moderation" you mentioned, with the intention to fend off low-quality reports:

If we had the ability to move bugs between projects, then we'd probably set up an inkscape-reporter project to capture public bug reports before moving real ones to the inkscape project itself.

I disagree with this idea from my personal standpoint as an "outsider": I sometimes fix bugs in open source software I use, but don't spend a significant part of my life with that. Certainly, psychology is an important factor in the decision whether I will spend my time on Inkscape or rather do something else.

As a user, it makes me feel welcome and well-respected that I can directly input bug reports and don't hang in some kind of moderation queue or "two-class society". The easier and the more directly accessible a project's reporting system is, the more I am inclined to spend time reporting bugs and possibly also patching some easier ones. (and of course, this is not about me personally, but more meant as an example for many users out there).

To avoid junk reports, I think it is the best to provide some kind of template which is shown when a bug report is created. Gitlab can do this via "description templates": https://gitlab.com/help/user/project/description_templates.md

Best Regards,

Max

Bryce, JFYI:

Gitlab has a couple more levels of access, e.g. Guest and Reporter (in addition to Developer, Master and Owner) status. Reporter status means they can manage bugs, but don't have access to the code.

Guest means they can look at things that someone allowed them to look at. It's kind of an 'honorary' or non-developing, non-bug-managing member.

More info here: https://gitlab.com/help/user/permissions.md

i.e. if someone does not fulfill the 2-patch-rule, they could still become a project member - if project policy wants to make use of the different levels that are available. (btw. I think I do have push access..., not that I'd ever make use of it, of course.)

Also, there's a distinction between group members and project members.

E.g. I am a member with Developer status of the Inkscape group, which contains a couple of projects, that can have their own, additional members. The higher level of access status decides which permissions one has - e.g. I have at least developer status for any sub-project, and have master status on some sub-projects.

So policy would need to decide whether to add new Inkscape code developers just to the /inkscape/inkscape project, or to the whole /inkscape group, giving them access also to translations, website, manual and possible other subprojects (not a bad thing, as long as critical stuff, like the branches the website pulls from, are still specially protected - and I don't think that vice versa is a good idea - i.e. someone makes two contributions to po files, and gets developer access to everything... so perhaps having the same level for all would be more consistent).

Maren

Am 14.06.2017 um 01:35 schrieb Bryce Harrington:

On Tue, Jun 13, 2017 at 02:17:37PM -0400, Martin Owens wrote:

...

Dear Bug hunters and Developers,

GitLab contact Connor Shea has asked us what we might need in the GitLab issues tracker to consider using it as our bug tracker instead of launchpad.

After talking with su_v and bryce on IRC, I've drafted this possible email detailing some of the issues:

https://inkscape.org/en/paste/11094/

Not particular to bug tracking exactly, but it would be nice if when people request access to the devel team, if it could automatically check that they fulfil the two patch rule.

Like, maybe, the emails sent to the admins could append a list of recent patches that were accepted and landed in trunk from the developee. It'd save some time having to verify they satisfy the requirements.

Bryce

---

Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel