On Wed, Mar 13, 2019 at 07:55:25PM +0100, Patrick Storz wrote:
Am 13.03.2019 um 19:05 schrieb Bryce Harrington:
On Tue, Mar 12, 2019 at 12:42:36AM +0100, Mihaela wrote:
The "Big Ideas" sound like a good candidate for the Epic feature in GitLab, although you need to upgrade to use it (maybe GitLab could sponsor Inkscape in this way? Any other useful GitLab features that aren't free?)We thought about that, although I figure if we keep to a high level of granularity we can probably just use a plain single kanban board. If it turns out everyone really likes kanban and we want to use it heavier, we could consider using gitlab epics, or perhaps one of the many other kanban services out there.
But what we need to decide right now is what to call it. We didn't have any solid thoughts, but a few ideas are: "Big ideas", "Blueprints", "Features", ... Do you have any good ideas?
As you mention "blueprints" and "features": How do we prevent this from becoming one of the following?
- Launchpad Blueprints, where a huge amount of unsorted ideas ended up, that nobody ever looked at.
- Launchpad "Wishlist" bugs, which were a vast amount of mostly unactionable ideas of varying usefulness which were often not more than a nice way of "closing" a report.
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.
Also you're asking for names already - but I think nobody except for the hackfest attendees knows what this feature is actually about and how it's supposed to work in the end. Are you planning a more detailed write-up on this?
Yep.
This is mostly just a continuation of the "What about feature requests" question we've been punting on since before the transition, although it came up at hackfest in context of the post-1.0 roadmap.
From the things I read between the lines I especially wonder: How are "ideas" selected? How does it differ from discussions we're having in inbox already? What issues is it trying to solve in the first place (i.e. why do we even need a new place)? And related to the above: What do you want to do differently compared to previous models that will make it more likely it'll work this time?
The same goes for the "Forecast" btw, which could use some explaining, too, unless you want to explain it by doing "it" (whatever "it" might be...)
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.
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.
Bryce