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