Re: Bug management for inkscape/inkscape

Names. New and Old are important.

Forecast party is an event where developers and users get together to
discuss specific features.

The schedule depends on the timing of the event.

A regular schedule will include 10 minutes at the start for which
problematic changes (things with code OR designs) can be shown and
quickly voted on. Presenters will be highly encouraged to post an
animated GIF to their flagged issue or merge request. Votes will be
posted to the issue, issues without GIFs will not be discussed. Votes
will be YES (change is good), NO (do not change) or RESEARCH (send the
idea to proper UX testing, should be very rare).

The rest of the time will be taken by discussion a single idea or
feature. The goal is to write up details into the forecast issue,
including doing research on how other programs handle the design, who
is interested or excited to work on the idea and what kind of release
schedule the feature if implemented would fall into.

The specific idea will be announce ahead of time.

The goal of the Forecast party is to increase visibility of
developments, to excite the developer community with new ideas and to
plan out when an exciting idea is a good idea to land.

This is only a very rough outline of the process I'm personally
thinking about.

Regards, Martin

On Wed, 2019-03-13 at 22:11 +0100, Patrick Storz wrote:
> Am 13.03.2019 um 21:40 schrieb Bryce Harrington:
> > Was thinking probably can follow the same process you suggested for
> > the
> > main bug tracker.  Everything goes into inbox, only the best, most
> > fleshed out (roadmap-ready) items would move on to this tracker.
> 
> And what do we gain from having a separate tracker instead of using 
> issues at inkscape/inkscape with the "feature request" label
> (especially 
> in the scenario where we allow only fleshed out proposals)?
> 
> I feel that this is working well already (and probably in-line with
> the 
> "forecast" idea). For example I've added my own plans as "feature 
> requests" for increased visibility and to give others the chance to 
> comment. For other well-defined projects we don't have assignees
> yet, 
> but for example the request for a continuously-built flatpak release 
> already triggered some relevant discussion and might have gained us
> a 
> potential contributor who 's interested in implementing the feature.
> As for splitting out feature requests into another sub-project I'm 
> afraid that it will actually decrease their visibility and makes it
> all 
> to easy to completely ignore them. Also it looses functionality, as
> we 
> won't be able to share the same labels / milestones easily (which
> mostly 
> apply to feature requests, too, I guess).
> 
> Looking forward to the write-up!
> 
> > Martin posted about this on the 5th, as part of the summary about
> > Friendly Mentorship concept from the hackfest, but I can explain it
> > in
> > more detail.
> 
> I remember. It read pretty vague, though, and I certainly don't 
> understand yet how the forecast (and the forecasting events) are
> meant 
> to work. That's why I asked.
> 
> 
> > In talking about the roadmap, I'd pointed out that it doesn't
> > generally
> > work very well as a top-down dictate, since developers tend to know
> > what
> > they plan to work on already, so instead it works best if
> > approached
> > more like a "forecast".  People liked that term better than
> > roadmap, and
> > it stuck in all the subsequent discussions.
> 
> That's the single thing I fully understood from Martin's
> explanation, 
> but what else does change except the name? ;-)
> 
> Our roadmap always was "what we should do", and we ended up mostly
> doing 
> something else, that's certainly not new. Does this simply mean devs
> are 
> encouraged to add what they want to work on to the forecast and we 
> abstain from adding "action items" for which we don't have assignees
> yet?
> 
> Could somebody elaborate more on the "forecast meetings"? Are they 
> simply meant as a monthly developer meetings (a bit like the board 
> meetings) where current and upcoming work can be discussed? Or is
> there 
> a more formal process involved? For example I've noticed the "to 
> forecast" label - how is it applied and what is the result of tagging
> an 
> issue report or feature request with it?
> 
> Cheers,
> Patrick
> 
> 
> 
> 
> _______________________________________________
> Inkscape-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel