On 12/09/2012, at 2:09 PM, Hans Dockter wrote: > Our gradle.org/roadmap is not up to date as we all know. I'm wondering what > we should do to improve the transparency of our planning and the accuracy of > our planning message. > > How can we realistically improve thi > > My idea is to use the design docs as the master data for our roadmap. Have > the capability to create a topic in GS like we do for roadmap topics today. > We would have an additional metadata field called design doc URL from which > we would retrieve the content of the forum posting. We would also provide > multiple metadata tuples as multiple items from gradle.org/roadmap are often > associated with one design doc (e.g. build comparison -> Maven migration, > Upgrade comparison). > > Thoughts?
I can't see a clear way forward, so let's step back. What exactly do want to achieve, in a very general sense, here? 1. Communicate what we are working on (implementing or designing) right now or soon 2. Communicate what we expect we will work on in the future 3. Explain why are working on something, and provide information on the scope (i.e. exactly what is this?) 4. Be open and transparent in the design process, allowing community members to observe Is that about right? What I don't like about the current roadmap is that it's kind of like a wishlist. To me, this is an attempt to avoid criticism that we don't have a certain feature and it's a dangerous game. I'm talking about items like “Unparalleled Command-Line Usability”, “Improving Console Output”, “Release Management” etc. I don't think they should be on this list at all. We have 3 communication channels: 1. gradle.org/roadmap 2. forums 3. design-docs #2 is the primary channel for communicating at a user level. This would be very high level discussion of the rationale and what it would allow users to do. #3 is the technical discussion, most users aren't going to care about this. The associated item from #2 could link to this. #1 provides an aggregated, summarised view #2 essentially. #3 has the most chance of being kept up to date, so we should probably drive any automation from there. Off the top of my head… 1. Split design-docs into 3 buckets; archive, active, planned. 2. For each item we want to publicise, we write a forum idea that is linked to the design-doc somehow. The bucket that the design-doc is in determines the state of the “item”: archive = complete, active = in progress, planned = planned. The bucket that the design-doc is in determines which roadmap the item shows up on: archive = none, active = /roadmap, planned = /long-term-roadmap The roadmap only shows items that have a forum post, if there's no forum post it's because it's not of interest to users and is an internal thing. The ongoing process: 1. Add the design-doc to the right bucket (probably starts in “planned”). 2. Write a forum post introducing the feature/item as it pertains to users, link to design-doc 3. Move the design-doc through the phases 4. If the name of the design-doc file changes, go and update the forum post I think that will allow us to keep things up to date without much work, and keep the roadmap realistic. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
