> http://felixge.de/2013/03/11/the-pull-request-hack.html
Interesting post. It at first seems radical, but on further reading Felix is clear that he means that quality, bug-free code is a prerequisite for committer status -- and that status can still be revoked. So while it's less despotic than the way some projects are currently run, there are still those who make the rules and whose who must obey them (I'm not saying this is a bad thing, just stating it). As Aaron notes, there's a sticking point of code style and that, to some degree, stands alone from code quality. It isn't a good idea to bend code style just to get bug fixes in. If style rules are not formally stated anywhere (and I mean a _lengthy_ explanation) I'd hesitate to directly commit because I have my own approach to most anything (beyond my love of ternary expressions, which I can suspend, there are plenty of outright obsessions). I would add that beyond code style and quality are wider project traditions-cum-standards. I have recommended previously that people look at the PHP Internals list so you can see that this major open-source product emerges from a mixture of individual wins, collaborative wins and bitter collaborative fails. We have run-ins over the RFC voting process, the commenting process, pluralities and majorities, you name it. And when it comes to features themselves, we often debate what PHP "is," and what it "is not," and the verdict is up to the oldest-timers and their choice can sound more like a grudge than divine wisdom. (They are also due credit for so much of the modern online experience, so this is not to take anything away from them as they are -- or should be -- legends. Perhaps the fact that youngsters respect Resig more than Rasmus forms part of the grudge.) In this light, I point you to the most recent active issue on the MooTools issue tracker. A user has noted that Core.Browser is broken in one well-demonstrated mobile scenario. A core dev has said that Core.Browser, which relies on navigator.userAgent, is deprecated enough that it will not be updated; the implication is that neither a pull request nor a self-commit would be allowed into the repo. Won't-fixing a non-security bug in a deprecated module is definitely sound. But what if we want to un-deprecate it at the same time that we fix it? AFAIK, there is no community voting process for un-deprecating a feature, so the idea of community committers is stopped in its tracks by cases like this. Please understand that I see why the issue was won't-fixed; I am just trying to broaden the discussion so that we don't get too far ahead of ourselves with the new "UberOpenMoo" idea. There are many, many rules and regs to think of. -- S. -- --- You received this message because you are subscribed to the Google Groups "MooTools Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to mootools-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
