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