Re: Issue tracking for Inkscape moves to Gitlab

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
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

_______________________________________________
Inkscape-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel