We definitely need one place (or one type of place) to find the task list for each book/document and indicate ownership for particular tasks. I like the more formal nature of including a file in each repo that requires agreement through the review process to change roadmap components. However, assigning a task to myself also requires the review process and I'm not sure we need that complexity for this particular type of change. A wiki helps the latter situation, but lacks control and history of the roadmap components. Maybe we can self-approve task assignments? On Tue, May 20, 2014 at 4:03 PM, Anne Gentle <anne at openstack.org> wrote: > Hi all, > I've proposed roadmaps to live in-repo for each book in the > openstack-manuals repository: > > https://review.openstack.org/94387 > https://review.openstack.org/94389 > https://review.openstack.org/94386 > https://review.openstack.org/94388 > https://review.openstack.org/94384 > https://review.openstack.org/94390 > https://review.openstack.org/94385 > > I'd like input on the process we can implement for these roadmaps. I'd > like bugs to be reserved for actual defects and blueprints to be reserved > for large coordinated efforts. > > Roadmap tasks are additional information that enhances the particular > guide targeted with the roadmap. A roadmap should give walk-up contributors > a list of things they could do if they're so inclined. How can a > contributor indicate they're working on a roadmap task so we avoid > duplication of effort? Submit a work-in-progress patch is all I have > proposed so far. Is that work-able? Let me know your thoughts on how to > make a roadmap work (and don't make me set up a docs-specs repo please). :) > > Thanks, > Anne > > _______________________________________________ > Openstack-docs mailing list > Openstack-docs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140520/93d8d286/attachment.html>