no access to Inkscape code repository on Gitlab
Hi, Is it just me, or have the permissions changed for browsing the Inkscape code on Gitlab? I have a shortcut for accessing Inkscape: https://gitlab.com/inkscape/inkscape I use this regularly just for curiosity. This link no longer works, unless I am signed in to Gitlab, which I typically am not. Even worse, if I use this link, and then go to the link that says: Explore projects on GitLab.com (no login needed) I find that the Inkscape project no longer exists. That is to say, many Inkscape-related projects are found, but Inkscape itself does not exist or cannot be found.
just checking, Alvin
-- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
hmm, the problem has magically disappeared.
sorry for the noise, Alvin
-- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
No magic involved, earlier today the repository had a visibility of "internal", now somebody flipped a switch and it's now "public".
On Sun, 14 Jan 2018, 5:15 p.m. alvinpenner, <penner@...1856...> wrote:
hmm, the problem has magically disappeared.
sorry for the noise, Alvin
-- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
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
That was me, sorry. Been fiddling with the gitlab settings to tighten permissions up a bit. Wasn't sure how it would impact non-logged in users, so thanks for the quick feedback.
Bryce
On Sun, Jan 14, 2018 at 04:19:54PM +0000, Mattia Rizzolo wrote:
No magic involved, earlier today the repository had a visibility of "internal", now somebody flipped a switch and it's now "public".
On Sun, 14 Jan 2018, 5:15 p.m. alvinpenner, <penner@...1856...> wrote:
hmm, the problem has magically disappeared.
sorry for the noise, Alvin
-- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
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
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
FYI I filed a bug for the issue (or at least an issue) I found during this: https://gitlab.com/gitlab-org/gitlab-ce/issues/42022
Not sure if this is what you hit Bryce (group level should be unaffected but a project level the UI for the setting to allow requesting access is broken).
Regards, Eduard
Am 14.01.2018 um 18:21 schrieb Bryce Harrington:
That was me, sorry. Been fiddling with the gitlab settings to tighten permissions up a bit. Wasn't sure how it would impact non-logged in users, so thanks for the quick feedback.
Bryce
On Sun, Jan 14, 2018 at 04:19:54PM +0000, Mattia Rizzolo wrote:
No magic involved, earlier today the repository had a visibility of "internal", now somebody flipped a switch and it's now "public".
On Sun, 14 Jan 2018, 5:15 p.m. alvinpenner, <penner@...1856...> wrote:
hmm, the problem has magically disappeared.
sorry for the noise, Alvin
-- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
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
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
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
On Mon, Jan 15, 2018 at 07:30:14PM +0100, Eduard Braun wrote:
FYI I filed a bug for the issue (or at least an issue) I found during this: https://gitlab.com/gitlab-org/gitlab-ce/issues/42022
Not sure if this is what you hit Bryce (group level should be unaffected but a project level the UI for the setting to allow requesting access is broken).
Thanks for filing it, yes that sounds exactly like the hitch that I hit. Guessing that maybe toggling the project to internal, unchecking it, and toggling back to public somehow fixed it, because the checkbox is visible there now.
Thanks muchly for investigating it.
Bryce
Regards, Eduard
Am 14.01.2018 um 18:21 schrieb Bryce Harrington:
That was me, sorry. Been fiddling with the gitlab settings to tighten permissions up a bit. Wasn't sure how it would impact non-logged in users, so thanks for the quick feedback.
Bryce
On Sun, Jan 14, 2018 at 04:19:54PM +0000, Mattia Rizzolo wrote:
No magic involved, earlier today the repository had a visibility of "internal", now somebody flipped a switch and it's now "public".
On Sun, 14 Jan 2018, 5:15 p.m. alvinpenner, <penner@...1856...> wrote:
hmm, the problem has magically disappeared.
sorry for the noise, Alvin
-- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
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
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
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
On Sun, 14 Jan 2018 09:21:33 -0800 Bryce Harrington <bryce@...961...> wrote:
That was me, sorry. Been fiddling with the gitlab settings to tighten permissions up a bit. Wasn't sure how it would impact non-logged in users, so thanks for the quick feedback.
Hi,
maybe related to this: I am not able to create new issues for the "inkscape" project.
When visiting https://gitlab.com/inkscape/inkscape/issues/new I get "404 - The page could not be found or you don't have permission to view it.".
Creating issues for other projects (e.g. lib2geom) seems to work.
I am regularly logged in to gitlab and I don't have special permissions for any Inkscape repository on gitlab.
Ciao, Antonio
Hi Antonio,
issues for the Inkscape project are handled at launchpad:
Bug list: https://bugs.launchpad.com/inkscape
Make new report: https://bugs.launchpad.net/inkscape/+filebug
Bug report info on website: https://inkscape.org/en/contribute/report-bugs/
You need to register with Ubuntu One.
Maren
Am 17.01.2018 um 17:39 schrieb Antonio Ospite:
On Sun, 14 Jan 2018 09:21:33 -0800 Bryce Harrington <bryce@...961...> wrote:
That was me, sorry. Been fiddling with the gitlab settings to tighten permissions up a bit. Wasn't sure how it would impact non-logged in users, so thanks for the quick feedback.
Hi,
maybe related to this: I am not able to create new issues for the "inkscape" project.
When visiting https://gitlab.com/inkscape/inkscape/issues/new I get "404 - The page could not be found or you don't have permission to view it.".
Creating issues for other projects (e.g. lib2geom) seems to work.
I am regularly logged in to gitlab and I don't have special permissions for any Inkscape repository on gitlab.
Ciao, Antonio
On Wed, 17 Jan 2018 19:01:19 +0100 Maren Hachmann <maren@...3165...> wrote:
Hi Antonio,
issues for the Inkscape project are handled at launchpad:
Bug list: https://bugs.launchpad.com/inkscape
Make new report: https://bugs.launchpad.net/inkscape/+filebug
Bug report info on website: https://inkscape.org/en/contribute/report-bugs/
You need to register with Ubuntu One.
Thanks for the remainder Maren.
I knew about the launchpad pages but I didn't check the "Report Bugs" page before asking, I just assumed that since the code was on gitlab, new bug reports had to be filed there too. My bad.
Ciao ciao, Antonio
Am 17.01.2018 um 19:46 schrieb Antonio Ospite:
On Wed, 17 Jan 2018 19:01:19 +0100 Maren Hachmann <maren@...3165...> wrote:
Hi Antonio,
issues for the Inkscape project are handled at launchpad:
Bug list: https://bugs.launchpad.com/inkscape
Make new report: https://bugs.launchpad.net/inkscape/+filebug
Bug report info on website: https://inkscape.org/en/contribute/report-bugs/
You need to register with Ubuntu One.
Thanks for the remainder Maren.
I knew about the launchpad pages but I didn't check the "Report Bugs" page before asking, I just assumed that since the code was on gitlab, new bug reports had to be filed there too. My bad.
Ciao ciao, Antonio
No problem. Yes, the bugs didn't move along with the code. There has been a little bit of discussion about this, but a decision about moving them / removing them / archiving them / keeping them on lp ... hasn't been made.
Maren
On Wed, Jan 17, 2018 at 11:23:34PM +0100, Maren Hachmann wrote:
Am 17.01.2018 um 19:46 schrieb Antonio Ospite:
On Wed, 17 Jan 2018 19:01:19 +0100 Maren Hachmann <maren@...3165...> wrote:
Hi Antonio,
issues for the Inkscape project are handled at launchpad:
Bug list: https://bugs.launchpad.com/inkscape
Make new report: https://bugs.launchpad.net/inkscape/+filebug
Bug report info on website: https://inkscape.org/en/contribute/report-bugs/
You need to register with Ubuntu One.
Thanks for the remainder Maren.
I knew about the launchpad pages but I didn't check the "Report Bugs" page before asking, I just assumed that since the code was on gitlab, new bug reports had to be filed there too. My bad.
Ciao ciao, Antonio
No problem. Yes, the bugs didn't move along with the code. There has been a little bit of discussion about this, but a decision about moving them / removing them / archiving them / keeping them on lp ... hasn't been made.
If anyone feels motivated to put some time into moving this forward, let me know. The next steps are analytical -- essentially requirements gathering, and assembling a listing of questions that need researched.
Should we move bugs to gitlab? Or stick with Launchpad? Or investigate other bug systems? Or something else completely?
There's several different constituencies with differing needs that'll need to be balanced. It'd be great if we could find a plan that works well for bug reporters, triagers, and developers.
Bryce
Add also the question: Should we have one system for users and another for developers?
There are pros and cons to a split, but if we have a technical issues tracker on gitlab and a user focused needs tracker somewhere else. I could see the benefits.
Best Regards, Martin Owens
On Wed, 2018-01-17 at 17:01 -0800, Bryce Harrington wrote:
let me know. The next steps are analytical -- essentially requirements gathering, and assembling a listing of questions that need researched.
Should we move bugs to gitlab? Or stick with Launchpad? Or investigate other bug systems? Or something else completely?
There's several different constituencies with differing needs that'll need to be balanced. It'd be great if we could find a plan that works well for bug reporters, triagers, and developers.
If we do move them can we get back to separate categories of bugs and feature requests like we had on sourceforge before we went to launchpad? I know we have blueprints on there too, but they always seemed over complicated for simple stuff. Never liked the way launchpad merged them.
Cheers
John
On 18 Jan 2018 3:57 pm, "Martin Owens" <doctormo@...400...> wrote:
Add also the question: Should we have one system for users and another for developers?
There are pros and cons to a split, but if we have a technical issues tracker on gitlab and a user focused needs tracker somewhere else. I could see the benefits.
Best Regards, Martin Owens
On Wed, 2018-01-17 at 17:01 -0800, Bryce Harrington wrote:
let me know. The next steps are analytical -- essentially requirements gathering, and assembling a listing of questions that need researched.
Should we move bugs to gitlab? Or stick with Launchpad? Or investigate other bug systems? Or something else completely?
There's several different constituencies with differing needs that'll need to be balanced. It'd be great if we could find a plan that works well for bug reporters, triagers, and developers.
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
Agreed, we can have two separate trackers for bugs and requests/whishlist (not necessarily on different platforms)
As for the platform, I'd rather move the bugs to gitlab and keep most things in a single integrated platfotm; but the main problem remains the import and triaging of existing bugs, some of which having some information in them sometimes (cf "bugs" thread from october).
On Thu, Jan 18, 2018 at 04:05:23PM +0000, John Cliff wrote:
If we do move them can we get back to separate categories of bugs and feature requests like we had on sourceforge before we went to launchpad? I know we have blueprints on there too, but they always seemed over complicated for simple stuff. Never liked the way launchpad merged them.
Yes, and I've heard this stated from a number of others too.
While moving to launchpad from sourceforge was a benefit, conflating these two types of issues was a drawback. The loss of being able to prioritize feature requests as we'd done in SF was particularly unfortunate.
I had high hopes for the Blueprints system, but frankly the design was flawed and the implementation of it never really evolved or even kept up with other advancements in LP. It had potential, but I have a lengthy list of changes I would like to have seen to make it useful to us.
Ideally, I would love to have an entirely separate system for organizing feature requests. It would allow us to prioritize and refine the ideas, organize them into project lists for GSoC and the like, feed into our Roadmap, facilitate crowdsourced funding, and stimulate development activities.
Anyway, all cards on the table for now, but I do suspect splitting these apart is going to be on everyone's must-have list. :-)
Bryce
Cheers
John
On 18 Jan 2018 3:57 pm, "Martin Owens" <doctormo@...400...> wrote:
Add also the question: Should we have one system for users and another for developers?
There are pros and cons to a split, but if we have a technical issues tracker on gitlab and a user focused needs tracker somewhere else. I could see the benefits.
Best Regards, Martin Owens
On Wed, 2018-01-17 at 17:01 -0800, Bryce Harrington wrote:
let me know. The next steps are analytical -- essentially requirements gathering, and assembling a listing of questions that need researched.
Should we move bugs to gitlab? Or stick with Launchpad? Or investigate other bug systems? Or something else completely?
There's several different constituencies with differing needs that'll need to be balanced. It'd be great if we could find a plan that works well for bug reporters, triagers, and developers.
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
Am 18.01.2018 um 21:45 schrieb Bryce Harrington:
Anyway, all cards on the table for now, but I do suspect splitting these apart is going to be on everyone's must-have list. :-)
I keep repeating myself in this respect but *if* we are to split issues and feature requests in my opinion it's also an absolute must-have to be able to easily move stuff between those.
* It happens all the time that a "bug" turns out to be simply a limitation of the software so it effectively becomes a feature request. * Also people sometimes report a feature request and it turns out the feature already exists but is broken, turning it into a bug. * Last but not least there are the reports in between which basically ask for changed functionality because the current logic is flawed (at least to some) - it's not even possible in those cases to clearly define wether it's a feature request or a bug report or neither of those because it needs discussion.
As an example I could imagine having a separate GitLab project like "inkscape-features" so we could easily move issues between "/inkscape" and "/inkscape-features" as necessary.
Obviously if we were able to win enough active bug wranglers for the project who could take the responsibility to scour through all the requests and reorganize them accordingly there *could* be two separate systems but given the desolate state of our current bugtracker I don't think it's a realistic option.
Regards, Eduard
On Thu, Jan 18, 2018 at 10:12:16PM +0100, Eduard Braun wrote:
Am 18.01.2018 um 21:45 schrieb Bryce Harrington:
Anyway, all cards on the table for now, but I do suspect splitting these apart is going to be on everyone's must-have list. :-)
I keep repeating myself in this respect but *if* we are to split issues and feature requests in my opinion it's also an absolute must-have to be able to easily move stuff between those.
- It happens all the time that a "bug" turns out to be simply a limitation of the software so it effectively becomes a feature request.
- Also people sometimes report a feature request and it turns out the feature already exists but is broken, turning it into a bug.
- Last but not least there are the reports in between which basically ask for changed functionality because the current logic is flawed (at least to some) - it's not even possible in those cases to clearly define wether it's a feature request or a bug report or neither of those because it needs discussion.
I tend to agree, but have to acknowledge that there's a risk of putting too much burden on end-users to select where to report their feedback, when they may simply not know enough to make that determination. Or at least may not feel comfortable with it.
Part of the argument of the two-layer approach would be to address this by having a one-stop-shop inbox that is friendly and suitable for non-technical users. And then a second layer where the individual items are broken out into more technically detailed repositories which are sensibly grouped in ways that are more manageable for triagers and developers.
So yeah, being able to move things easily from the friendly 1st-layer inbox into the appropriate 2nd-layer is critically important (if it's hard to move things, no one will bother and it'll be piles of fail).
As an example I could imagine having a separate GitLab project like "inkscape-features" so we could easily move issues between "/inkscape" and "/inkscape-features" as necessary.
Having everything contained on the one platform would likely have some benefit to it. gitlab's trackers also allow defining tags and stuff per-tracker, so we could have the bug tracker have bug-oriented tagging and a feature tracker with feature-oriented tagging.
A question in my mind is what the workflow for feature requests should be, and if that workflow can be modeled appropriately within gitlab.
But this is a good idea and should be considered further.
Obviously if we were able to win enough active bug wranglers for the project who could take the responsibility to scour through all the requests and reorganize them accordingly there *could* be two separate systems but given the desolate state of our current bugtracker I don't think it's a realistic option.
Yes, there's a fair point there.
Bug triage is a considerable amount of work - largely invisible, often thankless. If the rate of incoming bugs is high, it can also be an overwhelming job. So approaches that depend on human labor to process bugs or that facilitate an increase in incoming data is going to exacerbate the situation. Approaches that can eliminate or automate processing steps would help. Approaches that shift the work to the reporter may help the triage problem but risk creating other problems.
For the two-layer system I've been mentioning, this in particular is a big risk, since the translation of issue from the first layer to the second would involve a significant amount of processing work, that isn't really automatable. My thought here is to structure it to be crowd-sourced - in other words, the external layer is messaged to be community-driven with community members earning rights to manage the content. I'm imagining something akin to StackExchange, or the old Ubuntu Brainstorm site. But with the advanced members being empowered to escalate items into the 2nd-level system.
With a strongly crowd-sourced 1st layer, then our triage staffing commitments would be just for the 2nd-level systems. There'll be fewer items there and they'd be higher quality so the workload would be smaller and easier.
I know a lot of companies used tiered tech support, this is basically the same approach, just with tier-1 being run and managed by the external community rather than the Inkscape project itself.
I wrote up a conceptual blue-sky user story for the last Vectors team meeting:
https://gitlab.com/inkscape/vectors/general/uploads/5fd013b6e716f16ccc85f862...
There's a bit more discussion about bug tracking ideas here:
https://gitlab.com/inkscape/vectors/general/issues/23
Bryce
Two quick comments:
Am 19.01.2018 um 01:40 schrieb Bryce Harrington:
I tend to agree, but have to acknowledge that there's a risk of putting too much burden on end-users to select where to report their feedback, when they may simply not know enough to make that determination. Or at least may not feel comfortable with it.
That's exactly why I think it's essential to have an easy possibility to move reports around as needed (i.e. let end-users try to make their best guess but without putting any pressure on them) and let more experienced folk sort out the reports which ended up in the wrong tracker. Good example is GitLab itself: They have three trackers (GitLab EE, GitLab CE and gitlab.com) and I never now where to report anything, so I make my best guess and report away - until now almost always somebody moved the bug according to whatever internal guidelines they have (I have no idea what they are but I feel perfectly fine with not caring ;-) ).
Part of the argument of the two-layer approach would be to address this by having a one-stop-shop inbox that is friendly and suitable for non-technical users. And then a second layer where the individual items are broken out into more technically detailed repositories which are sensibly grouped in ways that are more manageable for triagers and developers.
Here I have to ask for a quick clarification:
* Up to now we were discussing about splitting bugs and feature requests in this mailing list thread * Here you are suggesting to split "user-facing" and "developer-facing" trackers
As I assume we don't want four trackers
* are "feature requests / user-facing" and "bugs / developer-facing" synonymous for you? (e.g. handle discussion/designing/prioritizing of features on the user side and only migrate bugs away from that tracker to the developer-facing tracker)? * or are we discussing an either/or possibility here? (e.g. either split features/bugs or split users/developers)
On Fri, Jan 19, 2018 at 02:20:46AM +0100, Eduard Braun wrote:
Two quick comments:
Am 19.01.2018 um 01:40 schrieb Bryce Harrington:
I tend to agree, but have to acknowledge that there's a risk of putting too much burden on end-users to select where to report their feedback, when they may simply not know enough to make that determination. Or at least may not feel comfortable with it.
That's exactly why I think it's essential to have an easy possibility to move reports around as needed (i.e. let end-users try to make their best guess but without putting any pressure on them) and let more experienced folk sort out the reports which ended up in the wrong tracker. Good example is GitLab itself: They have three trackers (GitLab EE, GitLab CE and gitlab.com) and I never now where to report anything, so I make my best guess and report away - until now almost always somebody moved the bug according to whatever internal guidelines they have (I have no idea what they are but I feel perfectly fine with not caring ;-) ).
Part of the argument of the two-layer approach would be to address this by having a one-stop-shop inbox that is friendly and suitable for non-technical users. And then a second layer where the individual items are broken out into more technically detailed repositories which are sensibly grouped in ways that are more manageable for triagers and developers.
Here I have to ask for a quick clarification:
- Up to now we were discussing about splitting bugs and feature requests in this mailing list thread
- Here you are suggesting to split "user-facing" and "developer-facing" trackers
As I assume we don't want four trackers
- are "feature requests / user-facing" and "bugs / developer-facing" synonymous for you? (e.g. handle discussion/designing/prioritizing of features on the user side and only migrate bugs away from that tracker to the developer-facing tracker)?
- or are we discussing an either/or possibility here? (e.g. either split features/bugs or split users/developers)
It's the latter. So if both splits were done there'd be three trackers (apologies if the ascii/unicode diagramming gets borked):
+-------------------+ | Friendly Feedback | +-------------------+ ↓ ↑ Crowdsourced Triaging ↓ ↓ +-----------+ +------------+ Feature ← | Feature | | Bug | → Bug Triager → | Request | | Report | ← Triager Team | Tracker | | Tracker | Team +-----------+ +------------+ ↓ ↓ Developers Developers Developers
Bryce
Am 19.01.2018 um 02:54 schrieb Bryce Harrington:
It's the latter. So if both splits were done there'd be three trackers (apologies if the ascii/unicode diagramming gets borked):
+-------------------+ | Friendly Feedback | +-------------------+ ↓ ↑ Crowdsourced Triaging ↓ ↓ +-----------+ +------------+Feature ← | Feature | | Bug | → Bug Triager → | Request | | Report | ← Triager Team | Tracker | | Tracker | Team +-----------+ +------------+ ↓ ↓ Developers Developers Developers
Thanks, sounds very reasonable!
Especially as the "Friendly Feedback" part is optional depending on whether we can make the "Crowdsourced Triaging" part work.
We could even experiment with those:
* If we can come up with a big unified system that makes everybody happy: Great! * Even if this fails we could adapt that part to distribute it across many shoulders. For example we currently have a lot of forums / social networks / Launchpad answers / etc. - all of them could be part of the larger network with some experienced people taking on a kind of "moderator" role to feed features/bugs into the core trackers.
Eduard
+-------------------+ | Friendly Feedback | +-------------------+ ↓ ↑ Crowdsourced Triaging ↓ ↓ +-----------+ +------------+ Feature ← | Feature | | Bug | → Bug Triager → | Request | | Report | ← Triager Team | Tracker | | Tracker | Team +-----------+ +------------+ ↓ ↓ Developers Developers Developers
If the Feature and Bug report trackers are on GitLab, I think a friendly feedback / crowd triaging app could be made to talk their API with medium difficulty.
If I were to craft one, I'd probably make it a separate project. If one already exists, then we could set that up localhost or staging to test it out.
But I'd like to make sure any existing system isn't designed to be the principle bug tracker firstly. Best Regards, Martin Owens
On Fri, Jan 19, 2018 at 11:43:23AM -0500, Martin Owens wrote:
+-------------------+ | Friendly Feedback | +-------------------+ ↓ ↑ Crowdsourced Triaging ↓ ↓ +-----------+ +------------+ Feature ← | Feature | | Bug | → Bug Triager → | Request | | Report | ← Triager Team | Tracker | | Tracker | Team +-----------+ +------------+ ↓ ↓ Developers Developers Developers
If the Feature and Bug report trackers are on GitLab, I think a friendly feedback / crowd triaging app could be made to talk their API with medium difficulty.
If I were to craft one, I'd probably make it a separate project. If one already exists, then we could set that up localhost or staging to test it out.
But I'd like to make sure any existing system isn't designed to be the principle bug tracker firstly.
Yes that, plus making sure there isn't already something off the shelf that could be put to the task with a bit of glue code. (I know of nothing offhand, but the FOSS world is large and this is not a particularly unusual need.)
Bryce
I like this idea too, so that we know that bugs in "bug report tracker" are actually reproducible and contain some info :)
How do you think we should proceed for our existing bugs ?
+-------------------+ | Friendly Feedback | +-------------------+ ↓ ↑ Crowdsourced Triaging ↓ ↓ +-----------+ +------------+Feature ← | Feature | | Bug | → Bug Triager → | Request | | Report | ← Triager Team | Tracker | | Tracker | Team +-----------+ +------------+ ↓ ↓ Developers Developers Developers
Bryce
On Thu, Jan 18, 2018 at 10:56:12AM -0500, Martin Owens wrote:
Add also the question: Should we have one system for users and another for developers?
There are pros and cons to a split, but if we have a technical issues tracker on gitlab and a user focused needs tracker somewhere else. I could see the benefits.
From what I've seen of how our users interact with the bug tracker, this
is certainly the direction I'm leaning. We discussed this a fair bit at the last Vectors team meeting, and hope to see some refinement of this approach.
However, at this stage I think we should keep all cards on the table, and focus on brainstorming and analysis. There's a number of different stakeholders, and it'd be too easy to jump to a solution that ends up being a poor fit for many (or too challenging to get implemented).
Do we have a wiki page setup for discussing/brainstorming bug tracker ideas? Maybe that'd be a good starting point?
Bryce
Best Regards, Martin Owens
On Wed, 2018-01-17 at 17:01 -0800, Bryce Harrington wrote:
let me know. The next steps are analytical -- essentially requirements gathering, and assembling a listing of questions that need researched.
Should we move bugs to gitlab? Or stick with Launchpad? Or investigate other bug systems? Or something else completely?
There's several different constituencies with differing needs that'll need to be balanced. It'd be great if we could find a plan that works well for bug reporters, triagers, and developers.
Am 18.01.2018 um 21:30 schrieb Bryce Harrington:
Do we have a wiki page setup for discussing/brainstorming bug tracker ideas? Maybe that'd be a good starting point?
Now we have:
http://wiki.inkscape.org/wiki/index.php/Bug_Reporting_Workflow
Maren
Am 22.02.2018 um 02:25 schrieb Maren Hachmann:
Am 18.01.2018 um 21:30 schrieb Bryce Harrington:
Do we have a wiki page setup for discussing/brainstorming bug tracker ideas? Maybe that'd be a good starting point?
Now we have:
http://wiki.inkscape.org/wiki/index.php/Bug_Reporting_Workflow
Maren
Wow, nice!
It reads a bit biased against Launchpad (which in many cases is justified but in others not really a platform issue but something we also need to figure out for whatever new service we might choose) but certainly catches the core points perfectly.
I'm not sure where discussion is meant to happen going forward (discussion on Wiki talk pages seems to be non-existing in the Inkscape Wiki), but two items I think I settled with myself in the meantime are:
* Filing Inkscape bugs at https://gitlab.com/inkscape/inkscape/issues and creating a (curated) feature tracker as a separate project (e.g. https://gitlab.com/inkscape/inkscape-features/issues)%C2%A0 sounds like a good option. Having a separate project for features could allow to make use of GitLab's wiki features / simple markdown files / snippets / the repository itself to develop and visualize the ideas until they are in a ready state for developers to work on (which should be indicated by a tag) * Importing bugs from Launchpad in an automated way does not make sense. One of the core points we're trying to solve is that the old tracker is flooded with unclear/incomplete/untriaged bugs - automatically migrating them to the new platform will make it even worse (by disconnecting the original authors) and achieve nothing but moving all platform issues we have with Launchpad, too. If we want to import old bugs it needs to be done manually (e.g. have the "Bug Triager" team from the sketch work on evaluating the old bugs starting at the high importance bugs working their way down - a highly non-trivial and exhausting task). A possibility to gather help (make the "crowdsource triaging part" work) and to determine which bugs are still worth looking at might be to post automated messages at all bugs explaining the tracker is being closed down and all issues which still persist in the current Inkscape Version (give download links) should be re-evaluated (explain how to test) and submitted to the new "friendly feedback hub" for triaging (include guidelines on how to "write a good bug report").
Best Regards, Eduard
Am 23.02.2018 um 01:47 schrieb Eduard Braun:
Am 22.02.2018 um 02:25 schrieb Maren Hachmann:
Am 18.01.2018 um 21:30 schrieb Bryce Harrington:
Do we have a wiki page setup for discussing/brainstorming bug tracker ideas? Maybe that'd be a good starting point?
Now we have:
http://wiki.inkscape.org/wiki/index.php/Bug_Reporting_Workflow
Maren
Wow, nice!
- Thanks :) I hope it's going to help us move forward with that topic, although it's not really a fun/rewarding topic to start with, as it entrails a lot of work, has a high potential for too much discussion. Hopefully it's not going to be a lot of trial and error.
It reads a bit biased against Launchpad (which in many cases is justified but in others not really a platform issue but something we also need to figure out for whatever new service we might choose) but certainly catches the core points perfectly.
- As for the bias, I think that's because I was listing current problems, and our current platform is launchpad... So, of course, the problems will have to do a great deal with launchpad...
But the page is not static, you can improve the texts. I think it would be very beneficial if the people who are most affected by a change in that system (i.e. devs) would make their needs and wants clear, possibly on that page. It's good to have the vectors team thinking about bug filing templates and welcoming workflows and to have a documentation person write up a summary of issues, but we cannot reasonably do anything without devs.
I'm not sure where discussion is meant to happen going forward (discussion on Wiki talk pages seems to be non-existing in the Inkscape Wiki), but two items I think I settled with myself in the meantime are:
- Filing Inkscape bugs at https://gitlab.com/inkscape/inkscape/issues and creating a (curated) feature tracker as a separate project (e.g. https://gitlab.com/inkscape/inkscape-features/issues)%C2%A0 sounds like a good option. Having a separate project for features could allow to make use of GitLab's wiki features / simple markdown files / snippets / the repository itself to develop and visualize the ideas until they are in a ready state for developers to work on (which should be indicated by a tag)
- Importing bugs from Launchpad in an automated way does not make sense. One of the core points we're trying to solve is that the old tracker is flooded with unclear/incomplete/untriaged bugs - automatically migrating them to the new platform will make it even worse (by disconnecting the original authors) and achieve nothing but moving all platform issues we have with Launchpad, too. If we want to import old bugs it needs to be done manually (e.g. have the "Bug Triager" team from the sketch work on evaluating the old bugs starting at the high importance bugs working their way down
- a highly non-trivial and exhausting task).
- We'd need a whole hackfest *month* dedicated to it... And then, I'm afraid, nobody would come, it's not fun to sort through old bugs... And it's not a task that any one group can do alone - devs of all specializations, users, testers etc. would all be needed to help. Even if we could get 20 persons to work on it, there'd still be 240 bugs per person... 10 a day - mmh, that sounds almost doable. Bugathon, anyone?...
A possibility to gather help (make the "crowdsource triaging part" work) and to determine which bugs are still worth looking at might be to post automated messages at all bugs explaining the tracker is being closed down and all issues which still persist in the current Inkscape Version (give download links) should be re-evaluated (explain how to test) and submitted to the new "friendly feedback hub" for triaging (include guidelines on how to "write a good bug report").
- That would be another way to do it. Advantage: no or very little work for us and a 'clean slate', Disadvantage: lots of info lost, users annoyed (unless someone can explain it to users in a really, really good way).
Kind Regards, Maren
Best Regards, Eduard
participants (9)
-
alvinpenner -
Antonio Ospite -
Bryce Harrington -
Eduard Braun -
John Cliff -
Marc Jeanmougin -
Maren Hachmann -
Martin Owens -
Mattia Rizzolo