
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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel