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:cloud lists fedoraproject org>?>> <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
>>
>>
>> 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/