On 12/04/2014 10:27 AM, Matt Micene wrote: > Based on a quick IRC conversation with Colin, I've been thinking about a > quick way to get some level of tracking for "project" level items vs > "component" level items. E.g., adding a new package to Atomic vs thread > safe OstreeSysroot for rpm-ostree. > > Since we're tracking the component source and web site in Github, I'm > proposing a way to use that system for milestones, proposals, architecture > changes, etc. It's probably not the best way, but it's something we can > get done quickly. What would be the best way, do you think? How hard will it be to transition if we start using this method and go to something else later? Quick and good enough is fine with me, as long as it doesn't leave a lot on the table or make scaling the project overly difficult as we grow. > Create a top level 'governance' repo in the Project Atomic top level. This > project would be the source for things like the Atomic Host Definition, > reference package list, test plans, etc. +1 > Using labels, we can use the Issue tracking for this repo for proposals, > non-component specific tasks (e.g., vagrant boxes), discussions, etc. > Labels can identify the intent of the issue (enhancement, comment, > architecture) and the domain (networking, orchestration, container > engine). Accepted proposals could turn into new issues on component repos. > > With issues, we can capture milestones and tasks, and get a rough idea of > what makes up Project Atomic 0.5, 0.6 without being tied to a specific > Fedora release. > > A few issues I see from the start. There's no direct tie between issues in > all the repos, but we could use issues to track issues, bad duplication and > I'd like a better way. We also have two spots for discussion in that case, > atomic-devel and github issues, tracking commentary could become > problematic. Can we send github issues to atomic-devel, I wonder, the way we send Trac discussions to cloud lists fedoraproject org? Separately, I think it's time we start considering more formal governance. My bias is towards something like an Apache Project Management Committee (PMC) where the general trend is towards consensus and people can be added as they show involvement without a specific number of board members or whatnot. Perhaps I should flesh that out a bit more and send a separate note. Best, jzb -- Joe Brockmeier | Principal Cloud & Storage Analyst jzb redhat com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/
Attachment:
signature.asc
Description: OpenPGP digital signature