>> Certain I'm opening a can of worms here but I really do feel the 'vote >> a committer in' policy puts an unnecessary barrier to community, >> contribution and adoption. > > Sounds like you're making too big a deal about the vote here.
Not my intent. Its not a big deal. (At all.) I think this is the root cause of the concern identified by Ross in how he perceives how we work (or worked, rather, in the past). > It's basically just about making sure that everyone agrees about the > "decent contribution" part, so except for the few extra days of delay > in letting the vote run its course is pretty much the only extra > overhead I see here (yes, the Incubator adds a bit of extra > complexity, but that's temporary). Is the vote perceived as a bigger > barrier than that? I guess this is the difference between estimating complexity vs time. =) There is no faster code than no code at all. I'm not proposing its more complex or more expensive by any order of magnitude but rather that it introduces a barrier that did not previously exist. I'm not advocating change or really care enough to go to some battle over this. Just an observation. > If not a vote, what (or who) would decide who gets commit access? Upon review of a few pull requests that would be successfully merged a committer (usually the guy doing said merge) would add the new person as a committer to save themselves the trouble in the future. Its is a different philosophy; we tend to believe that folks are here to the right thing first. This isn't a trivial assumption; I believe it creates a community of mutual trust, respect, and happens to also save on the costs of policing and associated bureaucracy.
