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