On Tue, Jan 15, 2019 at 10:13:46AM +0000, C R wrote:

Yea, I thought only 1.0 Alpha or newer should be reported on GitLab. Also, I'm completing the video tutorial on how to report bugs (the whole process, including preliminary stuff) today. This video will coincide with the 1.0 Alpha release planned for tomorrow.

Lemme know. -C

We can certainly put the emphasis more on 1.0alpha bugs in gitlab, but I don't think it's a problem if 0.92.x bugs are filed there as well. After all, we want to eventually migrate off Launchpad, but are going to continue supporting the 0.92.x series as LTS even post-1.0.

My guess is that as people get comfortable with gitlab, there's going to be less incentive to spend time in LP, so if there are 0.92.4 bugs there, they stand a high risk of falling through the cracks.

For bug migration, of course the priority for efforts should be on bugs reproducible in trunk, so it makes sense to encourage their focus on 1.0alpha. But if they find some 0.92.4 bugs that in their judgment seem worth migration, I don't see why we wouldn't allow it.

I apologize for the confusion on this - looking back I see Mc raised this exact point at the last board meeting, but it did not get discussion. FWIW, the specific action item I was working is this one:

Nov 02 11:20:58 <bryce> ACTION: Announce move to gitlab for new Inkscape & 2geom bug reports, once inkscape 1.0-alpha is released [bryce]

I can see there is some ambiguity in the wording, and apologize for not checking that we were on the same page here before putting out the announcement. I think it'll be okay, though, and I think people are going to enjoy the shift to gitlab.

Bryce

On Tue, Jan 15, 2019 at 10:09 AM Marc Jeanmougin <marc@...3062...> wrote:

...

...

3. Bugs in Launchpad that are still reproducible in Inkscape 0.92.4 or newer can be re-filed on Gitlab and closed on Launchpad.

1.0-alpha or newer, right ?

--

Mc

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

I could try to do that. But I need specifics.

Is the only thing that needs to be changed is the link (and supporting text around the link, if necessary)? Should the link go to https://gitlab.com/inkscape/inkscape/issues, or directly to open a new Issue form?

Of course I'll list every change for translators and send it to you :-)

I'm probably not the best person to update the wiki. I'm not very familiar with it.

All best, brynn

-----Original Message----- From: Maren Hachmann Sent: Tuesday, January 15, 2019 8:08 AM To: inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Hi,

could someone help web content editors by browsing the website and looking for places that require updating?

I think it's probably FAQ, the bug report page, contribute testing, and develop pages.

Then there must also be some Wiki pages.

I'm currently a bit busy with other stuff, so I'd appreciate if someone gave me a list with links + screenshots or similar.

Or, if someone updated the pages, that would be cool - but then I'd still need a list (preferably with screenshots), for being able to notify translators.

Maren

Am 15.01.19 um 10:56 schrieb Bryce Harrington:

Hi all,

As of this week, the Inkscape project is shifting to Gitlab for issue tracking in place of Launchpad.

https://gitlab.com/groups/inkscape/-/issues

We've been using Gitlab for our code hosting and other purposes for a year and a half now[1], and have found it to be reliable and convenient. We didn't migrate Issue Tracking until now, so we could take time to make sure we had a plan:

1. Going forward, new bug reports should be filed only in Gitlab.

2. Launchpad will remain available as a historical archive of our bug reports. Filing bugs there will remain possible for now, but discouraged.

3. Bugs in Launchpad that are still reproducible in Inkscape 0.92.4 or newer can be re-filed on Gitlab and closed on Launchpad.

We are planning efforts to help organize the migration work and keep track of progress. More info on this will be coming soon.

Eventually, when the necessary bugs have been migrated, bug reporting in Launchpad will be shut off.

We're enthused about this change, and hope you too will find gitlab a more user friendly way to report issues, and we'd love your help triaging and solving Inkscape bugs.

Bryce

1: https://inkscape.org/news/2017/06/10/inkscape-moves-gitlab/

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

_______________________________________________ Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs

If either 0.92.4 or 1.0 alpha is about to be released, can't the edits just say 'from now on'? (Not really "from now on" specifically, but in effect it would be - here's where new bug reports go now.) Because users wouldn't be reporting bugs for 0.92.3 or older, after 0.92.4 is released, would they?

Thanks, brynn

-----Original Message----- From: Maren Hachmann Sent: Tuesday, January 15, 2019 9:19 AM To: brynn ; inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Am 15.01.19 um 17:08 schrieb brynn:

I could try to do that. But I need specifics.

- Thank you, Brynn.

Is the only thing that needs to be changed is the link (and supporting text around the link, if necessary)?

- No, the new policy about both bug trackers needs to be mentioned and explained on the 'report bugs' page, at least.

However, for that we still need a reply from Bryce about the Inkscape version that applies to. Wait for that before you start, please.

I can see why he said 0.92.4 and higher - because that's what is currently under development. I don't know what Marc's rationale is for only intending to do this for alpha and higher. Maybe there was some kind of misunderstanding in their communication earlier, dunno, just know that we need to know before we make any changes, and even before we publish the release news article...

On the other pages, probably a simple switch is sufficient, or change to a link to report bugs page if suitable, to have 1 central place that needs to be updated instead of multiple places.

Should the link go to https://gitlab.com/inkscape/inkscape/issues, or directly to open a new Issue form?

- Better allow users to search for duplicates first, so not the new issue form.

Of course I'll list every change for translators and send it to you :-)

- Thank you, that will be awesome.

I'm probably not the best person to update the wiki. I'm not very familiar with it.

- If you find something that needs updating, you can let us know here, then.

Maren

All best, brynn

-----Original Message----- From: Maren Hachmann Sent: Tuesday, January 15, 2019 8:08 AM To: inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Hi,

could someone help web content editors by browsing the website and looking for places that require updating?

I think it's probably FAQ, the bug report page, contribute testing, and develop pages.

Then there must also be some Wiki pages.

I'm currently a bit busy with other stuff, so I'd appreciate if someone gave me a list with links + screenshots or similar.

Or, if someone updated the pages, that would be cool - but then I'd still need a list (preferably with screenshots), for being able to notify translators.

Maren

Am 15.01.19 um 10:56 schrieb Bryce Harrington:

...

Hi all,

As of this week, the Inkscape project is shifting to Gitlab for issue tracking in place of Launchpad.

https://gitlab.com/groups/inkscape/-/issues

We've been using Gitlab for our code hosting and other purposes for a year and a half now[1], and have found it to be reliable and convenient. We didn't migrate Issue Tracking until now, so we could take time to make sure we had a plan:

1. Going forward, new bug reports should be filed only in Gitlab.

2. Launchpad will remain available as a historical archive of our bug reports. Filing bugs there will remain possible for now, but discouraged.

3. Bugs in Launchpad that are still reproducible in Inkscape 0.92.4 or newer can be re-filed on Gitlab and closed on Launchpad.

We are planning efforts to help organize the migration work and keep track of progress. More info on this will be coming soon.

Eventually, when the necessary bugs have been migrated, bug reporting in Launchpad will be shut off.

We're enthused about this change, and hope you too will find gitlab a more user friendly way to report issues, and we'd love your help triaging and solving Inkscape bugs.

Bryce

1: https://inkscape.org/news/2017/06/10/inkscape-moves-gitlab/

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs

On Tue, Jan 15, 2019 at 10:07:19AM -0700, brynn wrote:

If either 0.92.4 or 1.0 alpha is about to be released, can't the edits just say 'from now on'? (Not really "from now on" specifically, but in effect it would be - here's where new bug reports go now.) Because users wouldn't be reporting bugs for 0.92.3 or older, after 0.92.4 is released, would they?

Not all users will know to install 0.92.4 immediately; Linux users will tend to upgrade when their distro upgrades them, and that could be some months out. So we can expect many users will be on 0.92.3 even after 0.92.4 is out, and may need encouragement to re-test on the newer version.

It's questionable that the developers will have much interest in working on 0.92.4 bug reports, but they'll certainly have little interest in bugs only affecting 0.92.3 or older.

Bryce

-----Original Message----- From: Maren Hachmann Sent: Tuesday, January 15, 2019 9:19 AM To: brynn ; inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Am 15.01.19 um 17:08 schrieb brynn:

...

I could try to do that. But I need specifics.

• Thank you, Brynn.

...

Is the only thing that needs to be changed is the link (and supporting text around the link, if necessary)?

• No, the new policy about both bug trackers needs to be mentioned and

explained on the 'report bugs' page, at least.

However, for that we still need a reply from Bryce about the Inkscape version that applies to. Wait for that before you start, please.

I can see why he said 0.92.4 and higher - because that's what is currently under development. I don't know what Marc's rationale is for only intending to do this for alpha and higher. Maybe there was some kind of misunderstanding in their communication earlier, dunno, just know that we need to know before we make any changes, and even before we publish the release news article...

On the other pages, probably a simple switch is sufficient, or change to a link to report bugs page if suitable, to have 1 central place that needs to be updated instead of multiple places.

...

Should the link go to https://gitlab.com/inkscape/inkscape/issues, or directly to open a new Issue form?

• Better allow users to search for duplicates first, so not the new

issue form.

...

Of course I'll list every change for translators and send it to you :-)

• Thank you, that will be awesome.

...

I'm probably not the best person to update the wiki. I'm not very familiar with it.

• If you find something that needs updating, you can let us know here, then.

Maren

...

All best, brynn

-----Original Message----- From: Maren Hachmann Sent: Tuesday, January 15, 2019 8:08 AM To: inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Hi,

could someone help web content editors by browsing the website and looking for places that require updating?

I think it's probably FAQ, the bug report page, contribute testing, and develop pages.

Then there must also be some Wiki pages.

I'm currently a bit busy with other stuff, so I'd appreciate if someone gave me a list with links + screenshots or similar.

Or, if someone updated the pages, that would be cool - but then I'd still need a list (preferably with screenshots), for being able to notify translators.

Maren

Am 15.01.19 um 10:56 schrieb Bryce Harrington:

...

Hi all,

As of this week, the Inkscape project is shifting to Gitlab for issue tracking in place of Launchpad.

https://gitlab.com/groups/inkscape/-/issues

We've been using Gitlab for our code hosting and other purposes for a year and a half now[1], and have found it to be reliable and convenient. We didn't migrate Issue Tracking until now, so we could take time to make sure we had a plan:

1. Going forward, new bug reports should be filed only in Gitlab.

2. Launchpad will remain available as a historical archive of our bug reports. Filing bugs there will remain possible for now, but discouraged.

3. Bugs in Launchpad that are still reproducible in Inkscape 0.92.4 or newer can be re-filed on Gitlab and closed on Launchpad.

We are planning efforts to help organize the migration work and keep track of progress. More info on this will be coming soon.

Eventually, when the necessary bugs have been migrated, bug reporting in Launchpad will be shut off.

We're enthused about this change, and hope you too will find gitlab a more user friendly way to report issues, and we'd love your help triaging and solving Inkscape bugs.

Bryce

1: https://inkscape.org/news/2017/06/10/inkscape-moves-gitlab/

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs

---

Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs

For this page: https://inkscape.org/contribute/report-bugs/

I had 6 or 7 detailed comments/edits explained for the new contents under "Search the bug trackers" which were added, but now I think I can say it easier this way. Most of that info either repeats info that's already mentioned elsewhere on the page, or can be.

Could I just edit the page, but not publish? Or would you like me to explain every change which I would suggest?

Why is it suggested that users who find a bug already mentioned in LP, to transfer it to GL? Aren't all the LP bugs going to be moved to GL anyway?

All best, brynn

-----Original Message----- From: Maren Hachmann Sent: Thursday, January 17, 2019 12:13 PM To: brynn ; inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Brynn, bug experts,

I've now updated these pages:

https://inkscape.org/develop/bug-management/ https://inkscape.org/develop/getting-started/ https://inkscape.org/contribute/translations/ https://inkscape.org/contribute/report-bugs/ https://inkscape.org/learn/faq/

which contained link and mention of the launchpad bug tracker (most still do).

Please review, and let me know when they are finalized (enough) for translation.

Maren

Am 15.01.19 um 18:07 schrieb brynn:

If either 0.92.4 or 1.0 alpha is about to be released, can't the edits just say 'from now on'? (Not really "from now on" specifically, but in effect it would be - here's where new bug reports go now.) Because users wouldn't be reporting bugs for 0.92.3 or older, after 0.92.4 is released, would they?

Thanks, brynn

-----Original Message----- From: Maren Hachmann Sent: Tuesday, January 15, 2019 9:19 AM To: brynn ; inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Am 15.01.19 um 17:08 schrieb brynn:

...

I could try to do that. But I need specifics.

• Thank you, Brynn.

...

Is the only thing that needs to be changed is the link (and supporting text around the link, if necessary)?

• No, the new policy about both bug trackers needs to be mentioned and

explained on the 'report bugs' page, at least.

However, for that we still need a reply from Bryce about the Inkscape version that applies to. Wait for that before you start, please.

I can see why he said 0.92.4 and higher - because that's what is currently under development. I don't know what Marc's rationale is for only intending to do this for alpha and higher. Maybe there was some kind of misunderstanding in their communication earlier, dunno, just know that we need to know before we make any changes, and even before we publish the release news article...

On the other pages, probably a simple switch is sufficient, or change to a link to report bugs page if suitable, to have 1 central place that needs to be updated instead of multiple places.

...

Should the link go to https://gitlab.com/inkscape/inkscape/issues, or directly to open a new Issue form?

• Better allow users to search for duplicates first, so not the new

issue form.

...

Of course I'll list every change for translators and send it to you :-)

• Thank you, that will be awesome.

...

I'm probably not the best person to update the wiki. I'm not very familiar with it.

• If you find something that needs updating, you can let us know here,

then.

Maren

...

All best, brynn

-----Original Message----- From: Maren Hachmann Sent: Tuesday, January 15, 2019 8:08 AM To: inkscape-devel@lists.sourceforge.net ; Inkscape-Docs Subject: Re: [Inkscape-docs] [Inkscape-devel] Issue tracking for Inkscape moves to Gitlab

Hi,

could someone help web content editors by browsing the website and looking for places that require updating?

I think it's probably FAQ, the bug report page, contribute testing, and develop pages.

Then there must also be some Wiki pages.

I'm currently a bit busy with other stuff, so I'd appreciate if someone gave me a list with links + screenshots or similar.

Or, if someone updated the pages, that would be cool - but then I'd still need a list (preferably with screenshots), for being able to notify translators.

Maren

Am 15.01.19 um 10:56 schrieb Bryce Harrington:

...

Hi all,

As of this week, the Inkscape project is shifting to Gitlab for issue tracking in place of Launchpad.

https://gitlab.com/groups/inkscape/-/issues

We've been using Gitlab for our code hosting and other purposes for a year and a half now[1], and have found it to be reliable and convenient. We didn't migrate Issue Tracking until now, so we could take time to make sure we had a plan:

1. Going forward, new bug reports should be filed only in Gitlab.

2. Launchpad will remain available as a historical archive of our bug reports. Filing bugs there will remain possible for now, but discouraged.

3. Bugs in Launchpad that are still reproducible in Inkscape 0.92.4 or newer can be re-filed on Gitlab and closed on Launchpad.

We are planning efforts to help organize the migration work and keep track of progress. More info on this will be coming soon.

Eventually, when the necessary bugs have been migrated, bug reporting in Launchpad will be shut off.

We're enthused about this change, and hope you too will find gitlab a more user friendly way to report issues, and we'd love your help triaging and solving Inkscape bugs.

Bryce

1: https://inkscape.org/news/2017/06/10/inkscape-moves-gitlab/

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs

Am 16.01.2019 um 03:55 schrieb Maren Hachmann:

I'd like to ask Marc, Patrick and Bryce to review the changes. https://inkscape.org/contribute/report-bugs/

Thanks for taking care of this!

I've done some minor edits to simplify / clarify (among others I tried to give a short explanation on why there are two trackers but without getting too verbose). Feel free to cross-check and iterate!

I guess we might want to include a link to the guide on how to migrate a bug once it's ready in the relevant line? (I think Chris was preparing one?)

As a general note I'm afraid some users were lazy and didn't check properly for duplicates before. Having two trackers will likely not make that any more probable. Even for everybody else it obviously involves additional effort. As I don't see a way to "solve" this (short of nuking or completely disregarding the old tracker), I tried at least to change the wording a bit to explain that reporters themselves might profit from searching for old bugs on Launchpad, too, instead of simply indicating that we don't want them to file duplicates even if the reasons would be obvious and the request warranted. (Actually I'm starting to realize that for these kinds of pages it's more helpful to pick a language that tries to explain how filing reports "properly" can be mutually advantageous for reporters and project members alike, instead of trying to explain from the point of view of either party).

Cheers Patrick

On Wed, Jan 16, 2019 at 07:27:47PM +0100, Patrick Storz wrote:

Am 16.01.2019 um 03:55 schrieb Maren Hachmann:

...

I'd like to ask Marc, Patrick and Bryce to review the changes. https://inkscape.org/contribute/report-bugs/

Thanks for taking care of this!

I've done some minor edits to simplify / clarify (among others I tried to give a short explanation on why there are two trackers but without getting too verbose). Feel free to cross-check and iterate!

I guess we might want to include a link to the guide on how to migrate a bug once it's ready in the relevant line? (I think Chris was preparing one?)

That would be great to include when it's available.

As a general note I'm afraid some users were lazy and didn't check properly for duplicates before. Having two trackers will likely not make that any more probable.

Yes, with two trackers in play, that's certainly going to be a concern.

(I tend not to mind if users post dupes - gitlab and launchpad make it easy enough to mark bugs as dupes. I'd rather have that then deal with a user that incorrectly decides they have the same issue as an existing report, when they don't, and end up sidetracking analysis discussion with what is effectively just noise...)

Even for everybody else it obviously involves additional effort. As I don't see a way to "solve" this (short of nuking or completely disregarding the old tracker)

Well, having a unified inbox on gitlab as you proposed may get us partway towards something like that. If we accept 0.92 bugs in gitlab (for 0.92.4 and newer) then we can be more aggressive at discouraging bug filing on launchpad - we can scrub all mention of it and all links to it from all our public pages.

Bryce

Related to this very question: What's the status on "friendly feedback" and the idea of separate (user- and developer-facing) trackers?

During the last discussions I was involved in there seemed to be a whish to keep especially     https://gitlab.com/inkscape/inkscape/issues "internal" in the sense that only developers / experienced users should directly open issues against the main project, so it would only contain valid and easily reproducible bug reports in the long run.

I think the intention was that the vast amount of "unfiltered" reports should be made against a "catch all" tracker for triaging, where the wider community could help to sort reports into the relevant sub-projects and opinions / feature requests / support requests / invalid reports could be caught early and answered accordingly (hopefully in a more friendly way than "not a bug, closing").

Is this still a goal or (to say it bluntly) do we just continue as-is, which will likely mean we just start fresh in collecting an unmanageable amount of bugs? ;-)

If we *were* to make this cut I feel like *now* would be the time to do so, before the inkscape/inkscape tracker is flooded with "random" reports triggered by the upcoming releases.

Cheers Patrick

Am 15.01.2019 um 17:54 schrieb Marc Jeanmougin:

...

I'll be glad to make a post in forums about this.  But is this the correct link?

https://gitlab.com/groups/inkscape/-/issues

Or is it this?  https://gitlab.com/inkscape/inkscape/issues

The first one shows all bugs from all the Inkscape projects (Inkscape, extensions, website, vectors…) while the second only pertains to Inkscape

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 1/15/19 8:43 PM, Bryce Harrington wrote:

I also worry about seeing an unmanageable amount of bug reports coming in. Hopefully that doesn't happen soon.

We got 13 new bug reports just this weekend on *launchpad* (where it's harder to submit than in gitlab^^) :

1 support question ("I cannot see a dialog") 1 untestable macos issue 1 multi-duplicate of a (now fixed) cairo problem (btw, was cairo code updated in .92.4?) 1 about trunk, 1 translation, 1 bug on .92.3, 2 on .92.3 but does not say it (incl. one wishlist), 1 on the website, 2 probable wishlist/would-be-nice without mention of the version, 1 mailing list discussion on .92.3 (works for some, not for him), 1 visual bug

...

1 multi-duplicate of a (now fixed) cairo problem (btw, was cairo code updated in .92.4?)

s/cairo/2geom/ , sorry, I got it wrong ><

Actually I think there was a slight misunderstanding: Rather than implementing a full-featured new piece of support software and delaying the issue migration to GitLab indefinitely, I was actually suggesting to use GitLab to implement the basic concept of friendly feedback today!

My suggestion is to create a single subproject like     https://gitlab.com/inkscape/inkscape-bugs that is used as the primary user-facing issue tracker from where reports can be triaged and sorted into the more technically oriented trackers of the suitable subprojects, e.g.     https://gitlab.com/inkscape/inkscape/     https://gitlab.com/inkscape/vectors/     https://gitlab.com/inkscape/extensions/     https://gitlab.com/inkscape/inkscape-web/     https://gitlab.com/inkscape/inkscape-docs/     https://gitlab.com/inkscape/lib2geom/     and many more...

From the sheer amount of these trackers it's pretty obvious it will be hard to impossible for users to find the correct tracker on their own, so the idea is to provide one single point of entry that can be used to report *any* Inkscape-related bug and doesn't require the reporter to have an in-depth knowledge of the internal workings of the project. (Let's be honest: Even the most experienced members of the project are not involved in all of the sub-projects that make up Inkscape today!)

If this additional layer is deemed to be unnecessary (i.e. the current plan) we have to expect people will use     https://gitlab.com/inkscape/inkscape/ as the "catch all" bug inbox. It will be hard to impossible to keep on top of it, especially if we do not start rigorously closing issues that are not clearly bugs (something we did *not* do in LP so far; we usually supported users where we could!). Unfortunately this is necessary as - despite your optimism Bryce - we simply don't have the resources to give every report the attention it deserves without jeopardizing the central function of this tracker, which is efficient developer-facing bug-tracking for the core program itself. In other words: There won't be a lot of room for "friendly feedback".

I hope I made myself clearer this time. If so my main point is that there's a window of opportunity here to avoid having mixed opinions / feature-requests / support requests / questions / etc. into the core program's tracker all over again (status quo in LP). However this window is closing fast - so think twice and choose wisely...

Cheers Patrick

Am 15.01.2019 um 20:43 schrieb Bryce Harrington:

Yeah, I would love to see this capability, and think it'd help users and developers a lot. And you're right this would be the perfect time to introduce something. But other than roughing in the concept, progress on implementing it has not moved very far forward. I'd love to see us work on introducing a solution for this in the future, so I'd like us to keep it as a long term goal, but I don't think it is worth delaying moving ahead on using gitlab issues.

I also worry about seeing an unmanageable amount of bug reports coming in. Hopefully that doesn't happen soon. If it does start to become a problem we'll need to rethink plans. There may be more than one way to solve this problem, so it's worth keeping open to alternate ideas.

Bryce

On Tue, Jan 15, 2019 at 06:35:41PM +0100, Patrick Storz wrote:

...

Related to this very question: What's the status on "friendly feedback" and the idea of separate (user- and developer-facing) trackers?

During the last discussions I was involved in there seemed to be a whish to keep especially     https://gitlab.com/inkscape/inkscape/issues "internal" in the sense that only developers / experienced users should directly open issues against the main project, so it would only contain valid and easily reproducible bug reports in the long run.

I think the intention was that the vast amount of "unfiltered" reports should be made against a "catch all" tracker for triaging, where the wider community could help to sort reports into the relevant sub-projects and opinions / feature requests / support requests / invalid reports could be caught early and answered accordingly (hopefully in a more friendly way than "not a bug, closing").

Is this still a goal or (to say it bluntly) do we just continue as-is, which will likely mean we just start fresh in collecting an unmanageable amount of bugs? ;-)

If we *were* to make this cut I feel like *now* would be the time to do so, before the inkscape/inkscape tracker is flooded with "random" reports triggered by the upcoming releases.

Cheers Patrick

Am 15.01.2019 um 17:54 schrieb Marc Jeanmougin:

...

...

I'll be glad to make a post in forums about this.  But is this the correct link?

https://gitlab.com/groups/inkscape/-/issues

Or is it this?  https://gitlab.com/inkscape/inkscape/issues

The first one shows all bugs from all the Inkscape projects (Inkscape, extensions, website, vectors…) while the second only pertains to Inkscape

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Am 16.01.2019 um 04:59 schrieb Bryce Harrington:

Ah, yes that does sound doable. Now that you mention it I do remember discussing this before. I'd totally be open to this.

OK, great to hear. I actually was a bit afraid I might have largely misinterpreted previous discussions. Good to know you don't think the suggestion is insane after all ;-).

If the incoming queue is to be general including for lib2geom, perhaps it should be named something more generally, like

https://gitlab.com/inkscape/report

Or

https://gitlab.com/inkscape/inbox

And presumably it's where we would want to direct inkscape.org/report?

I'm open to wording. Historically we chose the "inkscape-*" prefix for pretty much everything (which is why I used it in my example) and as of now I think lib2geom can still be seen as a part of Inkscape, but yes, we certainly can pick a shorter / better name.

* I was considering "helpdesk" and "support" but discarded those as we probably shouldn't suggest in any way that general support requests should be directed there, but underline the bug/issue tracker aspect * I was considering a plain "bugs" or "issues" but we'd end up filing bugs/issues at "https://gitlab.com/inkscape/bugs/issues" or "https://gitlab.com/inkscape/issues/issues" (I think the problem of redundancy is obvious here...) * I like the general idea of "report" / "inbox" but it might lack the central piece of information on *what* is reported here / *what* the inbox is for

If we stick with the "inkscape.org/report" shortcut, I can totally see "report" working, though. However I remember Thomas raising concerns about this very shortcut, so there might be room for an even better option.

Yes, and there is also a desire to direct wishlist issues to something else, and this approach would enable doing that.

Better yet: It would create a space where these could be freely discussed until a sufficient consensus has formed on how a new feature should actually look. That's something we were missing in Launchpad! (Yes, there were blueprints, but it was so kludgy to use no real discussion ever took place, which made many feature requests / wishlist items completely useless as even if a developer wanted to work on them there was no baseline on what implementation actually made the most sense to users).

We have some issue tickets open on how we should handle the bug tracker, I'll review through those, and see if we can reuse one of them to discuss this plan.

Thanks, looking forward to it. I think a lot of relevant discussion already happened in https://gitlab.com/inkscape/infra/services/issues/1 - as a matter of fact I just realized I actually made the exact suggestion there, too, and I still agree with my idea of an "inbox"-like tracker ;-)

Bryce

...

Cheers Patrick

Am 15.01.2019 um 20:43 schrieb Bryce Harrington:

...

Yeah, I would love to see this capability, and think it'd help users and developers a lot. And you're right this would be the perfect time to introduce something. But other than roughing in the concept, progress on implementing it has not moved very far forward. I'd love to see us work on introducing a solution for this in the future, so I'd like us to keep it as a long term goal, but I don't think it is worth delaying moving ahead on using gitlab issues.

I also worry about seeing an unmanageable amount of bug reports coming in. Hopefully that doesn't happen soon. If it does start to become a problem we'll need to rethink plans. There may be more than one way to solve this problem, so it's worth keeping open to alternate ideas.

Bryce

On Tue, Jan 15, 2019 at 06:35:41PM +0100, Patrick Storz wrote:

...

Related to this very question: What's the status on "friendly feedback" and the idea of separate (user- and developer-facing) trackers?

During the last discussions I was involved in there seemed to be a whish to keep especially     https://gitlab.com/inkscape/inkscape/issues "internal" in the sense that only developers / experienced users should directly open issues against the main project, so it would only contain valid and easily reproducible bug reports in the long run.

I think the intention was that the vast amount of "unfiltered" reports should be made against a "catch all" tracker for triaging, where the wider community could help to sort reports into the relevant sub-projects and opinions / feature requests / support requests / invalid reports could be caught early and answered accordingly (hopefully in a more friendly way than "not a bug, closing").

Is this still a goal or (to say it bluntly) do we just continue as-is, which will likely mean we just start fresh in collecting an unmanageable amount of bugs? ;-)

If we *were* to make this cut I feel like *now* would be the time to do so, before the inkscape/inkscape tracker is flooded with "random" reports triggered by the upcoming releases.

Cheers Patrick

Am 15.01.2019 um 17:54 schrieb Marc Jeanmougin:

...

...

I'll be glad to make a post in forums about this.  But is this the correct link?

https://gitlab.com/groups/inkscape/-/issues

Or is it this?  https://gitlab.com/inkscape/inkscape/issues

The first one shows all bugs from all the Inkscape projects (Inkscape, extensions, website, vectors…) while the second only pertains to Inkscape

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Following Patrick's proposal and feedback collected from several others, I've set up a new project in the Inkscape gitlab called "Inbox".

https://gitlab.com/inkscape/inbox/issues/new

The concept is straightforward - we direct all user feedback to this one place where it is collected, curated, and fleshed out. Triagers look for well-formed reports that meet the requirements for the developer-oriented trackers (inkscape, extensions, lib2geom, vectors, inkscape-web, inkscape-docs, etc.) and promote them to that tracker.

The intention is to make it easy for users to submit feedback, but to save developers from being innundated with support requests and incomplete bug reports. The expectation is that this will be a community-curated space, where people can brainstorm on features, share tips on figuring out bugs, and assist each other in revising bug reports to a point they can be escalated.

A few tasks:

0. Let me know if there are any issues with this plan, or ways we can improve it. In particular, is there more we could do to streamline and simplify the UX?

1. Please change the inkscape.org/report redirect to go to

https://gitlab.com/inkscape/inbox/issues/new

2. Please add a redirect inkscape.org/inbox to go to

https://gitlab.com/inkscape/inbox/issues

3. Adjust our 1.0alpha bug reporting guidelines to direct users to these addresses.

4. I posted a sample report (#3) to trial run how this should work. Help me turn this into a "perfect" bug report.

5. We've discussed having a separate place to hold feature requests. But how should this be set up? Should we create a separate project to hold the finished feature requests? If so what should it be called? (inkscape-feature-requests? inkscape-blueprints? ...?)

6. We're going to need to build a sturdy and vibrant team of triagers. Help collect ideas on how to achieve this.

Bryce

On Wed, Jan 16, 2019 at 07:23:55PM -0800, Bryce Harrington wrote:

On Wed, Jan 16, 2019 at 07:55:10PM +0100, Patrick Storz wrote:

...

...

If the incoming queue is to be general including for lib2geom, perhaps it should be named something more generally, like

https://gitlab.com/inkscape/report

Or

https://gitlab.com/inkscape/inbox

And presumably it's where we would want to direct inkscape.org/report?

I'm open to wording. Historically we chose the "inkscape-*" prefix for pretty much everything (which is why I used it in my example) and as of now I think lib2geom can still be seen as a part of Inkscape, but yes, we certainly can pick a shorter / better name.

...

From a future-proofing point of view, I can see us including things

under our umbrella that are even more distinct from the inkscape core codebase. For instance we've talked about splitting out some of the 3rd party pieces currently integrated into Inkscape that have no active upstream anymore; so having them in gitlab projects with their own names without an inkscape- prefix, would be logical. If users will be filing bugs about those components to us, then would be useful to place those bug reports with those packages.

...

• I was considering "helpdesk" and "support" but discarded those as we probably shouldn't suggest in any way that general support requests should be directed there, but underline the bug/issue tracker aspect
• I was considering a plain "bugs" or "issues" but we'd end up filing bugs/issues at "https://gitlab.com/inkscape/bugs/issues" or "https://gitlab.com/inkscape/issues/issues" (I think the problem of redundancy is obvious here...)

Agreed on both counts.

...

• I like the general idea of "report" / "inbox" but it might lack the central piece of information on *what* is reported here / *what* the inbox is for

There will be some surrounding context I'm sure, but in general that is a fair point. There may be some cruft to be weeded out.

...

If we stick with the "inkscape.org/report" shortcut, I can totally see "report" working, though. However I remember Thomas raising concerns about this very shortcut, so there might be room for an even better option.

Do you remember the concerns offhand? Would "inbox" address them?

...

...

Yes, and there is also a desire to direct wishlist issues to something else, and this approach would enable doing that.

Better yet: It would create a space where these could be freely discussed until a sufficient consensus has formed on how a new feature should actually look. That's something we were missing in Launchpad! (Yes, there were blueprints, but it was so kludgy to use no real discussion ever took place, which made many feature requests / wishlist items completely useless as even if a developer wanted to work on them there was no baseline on what implementation actually made the most sense to users).

Ah, quite true. And yes, blueprints looked useful when we started, but never really panned out.

...

...

We have some issue tickets open on how we should handle the bug tracker, I'll review through those, and see if we can reuse one of them to discuss this plan.

Thanks, looking forward to it. I think a lot of relevant discussion already happened in https://gitlab.com/inkscape/infra/services/issues/1 - as a matter of fact I just realized I actually made the exact suggestion there, too, and I still agree with my idea of an "inbox"-like tracker ;-)

That's probably where I remember the idea from then. I'll give it a look and maybe start getting it set up.

Bryce

...

...

Bryce

...

Cheers Patrick

Am 15.01.2019 um 20:43 schrieb Bryce Harrington:

...

Yeah, I would love to see this capability, and think it'd help users and developers a lot. And you're right this would be the perfect time to introduce something. But other than roughing in the concept, progress on implementing it has not moved very far forward. I'd love to see us work on introducing a solution for this in the future, so I'd like us to keep it as a long term goal, but I don't think it is worth delaying moving ahead on using gitlab issues.

I also worry about seeing an unmanageable amount of bug reports coming in. Hopefully that doesn't happen soon. If it does start to become a problem we'll need to rethink plans. There may be more than one way to solve this problem, so it's worth keeping open to alternate ideas.

Bryce

On Tue, Jan 15, 2019 at 06:35:41PM +0100, Patrick Storz wrote:

...

Related to this very question: What's the status on "friendly feedback" and the idea of separate (user- and developer-facing) trackers?

During the last discussions I was involved in there seemed to be a whish to keep especially     https://gitlab.com/inkscape/inkscape/issues "internal" in the sense that only developers / experienced users should directly open issues against the main project, so it would only contain valid and easily reproducible bug reports in the long run.

I think the intention was that the vast amount of "unfiltered" reports should be made against a "catch all" tracker for triaging, where the wider community could help to sort reports into the relevant sub-projects and opinions / feature requests / support requests / invalid reports could be caught early and answered accordingly (hopefully in a more friendly way than "not a bug, closing").

Is this still a goal or (to say it bluntly) do we just continue as-is, which will likely mean we just start fresh in collecting an unmanageable amount of bugs? ;-)

If we *were* to make this cut I feel like *now* would be the time to do so, before the inkscape/inkscape tracker is flooded with "random" reports triggered by the upcoming releases.

Cheers Patrick

Am 15.01.2019 um 17:54 schrieb Marc Jeanmougin: > > I'll be glad to make a post in forums about this.  But is this the > > correct link? > > > > https://gitlab.com/groups/inkscape/-/issues > > > > Or is it this?  https://gitlab.com/inkscape/inkscape/issues > > > The first one shows all bugs from all the Inkscape projects (Inkscape, > extensions, website, vectors…) while the second only pertains to Inkscape > > > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Am 17.01.2019 um 09:53 schrieb doctormo@...400...:

On Wed, 2019-01-16 at 23:28 -0800, Bryce Harrington wrote:

...

1. Please change the inkscape.org/report redirect to go to

   https://gitlab.com/inkscape/inbox/issues/new

2. Please add a redirect inkscape.org/inbox to go to

   https://gitlab.com/inkscape/inbox/issues

Done.

Hi Martin,

just noticed inkscape.org/report leads to

https://gitlab.com/inkscape/inkscape/issues

instead of

https://gitlab.com/inkscape/inbox/issues

Could you correct this when you find the time? (inkscape.org/report works as expected)

Cheers, Patrick

Am 17.01.19 um 08:28 schrieb Bryce Harrington:

Following Patrick's proposal and feedback collected from several others, I've set up a new project in the Inkscape gitlab called "Inbox".

https://gitlab.com/inkscape/inbox/issues/new

...

A few tasks:

0. Let me know if there are any issues with this plan, or ways we can improve it. In particular, is there more we could do to streamline and simplify the UX?

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?

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

1. Please change the inkscape.org/report redirect to go to

   https://gitlab.com/inkscape/inbox/issues/new

2. Please add a redirect inkscape.org/inbox to go to

   https://gitlab.com/inkscape/inbox/issues

3. Adjust our 1.0alpha bug reporting guidelines to direct users to these addresses.

- I will make preliminary changes at https://inkscape.org/contribute/report-bugs/ , but I suppose there will still be further adaptations required. Please someone from the bug wranglers adapt as you see fit. Please notify me or translators mailing list when you are done.

I will also update the news article for this and the releases app contents.

Instructions for bug triagers at https://inkscape.org/develop/bug-management/ need to be updated, too. We need a volunteer for this task who is familiar with bug triage and can come up with a suitable workflow.

I will make a preliminary update there, adding the new link, but I will not dive into explanations etc. Whoever does the final update, please notify me or translators mailing list when you are done.

Maren

Am 17.01.19 um 17:18 schrieb Maren Hachmann:

Am 17.01.19 um 16:56 schrieb Maren Hachmann:

...

Am 17.01.19 um 08:28 schrieb Bryce Harrington:

...

...

...

A few tasks:

0. Let me know if there are any issues with this plan, or ways we can improve it. In particular, is there more we could do to streamline and simplify the UX?

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?

Who is supposed to watch for duplicates now?

• Users?
• Triagers?
• Developers?

• One more question/thing to decide upon:

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?

And another one: please update the bug reporting template at https://gitlab.com/inkscape/inbox/issues/new if you want quality reports from users. It's currently near empty, except for:

"How do you think Inkscape could be improved?"

Maren

Maren

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

On Thu, Jan 17, 2019 at 05:18:21PM +0100, Maren Hachmann wrote:

Am 17.01.19 um 16:56 schrieb Maren Hachmann:

...

Am 17.01.19 um 08:28 schrieb Bryce Harrington:

...

...

...

A few tasks:

0. Let me know if there are any issues with this plan, or ways we can improve it. In particular, is there more we could do to streamline and simplify the UX?

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?

Who is supposed to watch for duplicates now?

• Users?
• Triagers?
• Developers?

• One more question/thing to decide upon:

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?

After playing with the settings a bit, as far as I can tell there is only one toggle for a project's issues, which simply controls whether it is publically visible or not as a whole. Setting it hides both the new bug form, and all existing bug reports. I'm not spotting a way to restrict bug filing to project members only, but allow visibility of bug reports to all, which is what we specifically need. Does anyone else know a better way to set this?

Bryce

Hi everyone,

First, it seems there is a misconfiguration: I can create issues for everything except the inbox.

Can someone please explain to me the benefit of a separate inbox compared to just tagging all valid bug reports with something like "bug" or "confirmed", and all others reports with "question"?

I'm not sure if I miss a point, but both the current "Inbox" and the "real bugtracker" could be views of the same bugtracker, just filtered by tags.

By splitting up into two trackers we loose a valuable feature of GitLab, where related bugs are automatically suggested if you create a new one in the *same* GitLab project, which means that duplicates will keep popping up in the inbox although the bug is already in the development tracker.

It seems that the main motivation of the inbox is to move away the very "low-quality", discussion-forum like entries. If this is the case, I think we should state that technically complete bug reports should shortcut the inbox and go directly to the issue tracker. It could also be a motivation that if you manage to completely fill out the "real bug" template, developers will be able to take care of the bug. To avoid the usual questions, the developer template should also include "Does the bug happen on the latest version? [link] (Please state the version number and result). Does the bug happen on the latest development version? [link to something like http://wiki.inkscape.org/wiki/index.php/Installing_Inkscape ] (Please state the version number and result.)".

In some answers it was suggested to close (make read-only?) the issue tracker for everyone except Inkscape developers. I don't like the idea, as it feels more like a closed company with front-desk and back-office, and less like a meeting of friendly people where you can simply join. A read-only bug tracker is also really annoying to downstream distributions and users with developer-like knowledge. They should not be forced to use the "newbie support forum" and have to wait until someone discovers their high-quality report and moves it to the real bugtracker.

Max