[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Roadmap / tracking for Project Atomic top level



This discussion seems to have stalled - I'm going to propose we take
Matt's suggestion of the repo to track issues, and suggest we use
something PEP-style for larger issues. (e.g. "let's discuss removing
tmux from the default JSON" probably doesn't require a PEP, system-wide
major issues do.)

Any objections? If nobody weighs in with a good reason against this by
Tuesday morning (16 December), then let's get started with it.

Matt - are you interested in setting up the repo if we go forward?

Thanks,

jzb

On 12/04/2014 05:27 PM, SGhosh wrote:
> On 12/04/2014 04:58 PM, Matt Micene wrote:
>>
>>
>> On Thu, Dec 4, 2014 at 4:16 PM, Joe Brockmeier <jzb redhat com
>> <mailto:jzb redhat com>> wrote:
>>
>>     On 12/04/2014 10:27 AM, Matt Micene wrote:
>>     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.
>>
>>
>>
>> Sure, Joe, call me out ;-),  I really don't know what the best way
>> is.  Trello and the Kanban board things seem more focused on status
>> not capture and discussion.  I've looked at a few "roadmap" tools,
>> which seem to be just Gantt chart tools that have different output. 
>> The other way would be an official Bugzilla / Trac / JIRA or something
>> and do it all in tickets, which seems to have a better initial
>> workflow but means another tool, logins, etc.  Everything seems to
>> have some missing focus or additional overhead that makes me not want
>> to bring it up as a starting point...  Hence the good not perfect.
>>
>> I found a few examples of other projects doing similar things on
>> Github, e.g. Docker, Node.js Advisory Board. Check out the labels and
>> milestones on their issue page. They have the "advantage" that this is
>> a single, eponymous project and codebase so they don't need a separate
>> section for 'governance'.
>> https://github.com/docker/docker/issues
>>
>> Unless we completely abandon Github, the data would remain, the
>> overall process should be tool agnostic, so I don't think we'd leave
>> anything behind, but scale could always be an issue.
>>
> Would something like a PEP be useful? Openshift has leveraged
> successfully as part of the major design discussion artifacts.
> 
> eg: https://github.com/openshift/openshift-pep
> 
>>
>>     Can we send github issues to atomic-devel, I wonder, the way we send
>>     Trac discussions to cloud lists fedoraproject org
>>     <mailto:cloud lists fedoraproject org>?
>>
>>
>> Hmm, IFTTT or Zapier?  Maybe add a stub user to the Org that watches
>> issues?  Not savvy enough with issues to really know our options here.
>>
>>     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.
>>
>>
>> +1
>>
>> Matt M (nzwulfin)
> 
> 
> 


-- 
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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]