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