On Mon, Mar 31, 2008 at 5:15 PM, Sean Cribbs <[EMAIL PROTECTED]> wrote:
> Radiant users and developers, > > Over the weekend I took the time to watch the presentation by Evan > Phoenix about Rubinius that was given at MountainWest RubyConf 2008, > available from confreaks.com (You should watch it, too!). I was mostly > interested in hearing where Rubinius was technically, but his talk took > a very different path in that it focused on how community is being > fostered in the project. His primary points were about encouraging > experimentation and lowering the bar of entry. Some of his comments > really struck home with me, which I'll paraphrase here: > > 1) A team of 'core committers' tends to stifle debate and > experimentation and marginalizes those who have differing opinions. > This also has the effect of slowing progress on the project when the > core team is unable to participate. If someone is enthusiastic about > contributing, that should be fostered, not squelched by a high barrier > to entry. > 2) If a project is open-source, it should be much more open than most > projects actually are. Rubinius gives 'commit bits' after the first > accepted patch. This promotes the feeling of a real community project, > rather than a closed, orchestrated one. > 3) Small changes often encompass some of the greatest effort. One > should allow small, incremental changes, no matter how tiny. > 4) It's ok to make mistakes. No one, even a 'core committer', is > infallible. Learn from your mistakes, document them, and move on. > > The pace of Radiant over the last few months has been slower than > snails. I want to remedy this. I also want to > make amends for the ways that I might have squelched dissent or > artificially slowed the progress of the project through over-engineering > the timeline and smashing potentially transformative ideas. > > To this end, I want to attempt an experiment. The first step is that I > would like to open up the codebase for more experimentation. I have > created a clone of the Radiant Subversion repository on GitHub > (http://github.com/seancribbs/radiant/tree/master). I encourage > everyone who is interested in hacking the Radiant codebase to fork it, > make your changes, and send me pull requests. During this experiment, > we will also be maintaining the traditional SVN repo and I will push > changes to it when necessary. For those who are familiar with 'git', > this should be an opportunity to try out that cool feature you've always > been wanting to build. That said, I'd like our basic ground-rule to > apply, namely, that any patch you submit should have adequate specs. > Although we like to pride ourselves on our specs, the coverage in > Radiant is still not exhaustive, so any patches that improve the quality > and quantity of specs are also greatly encouraged. > > The second step is that I am going to start restructuring my time to > give Radiant the TLC that it needs. I want to be a more nurturant > parent. Earlier this year, John Long asked me to take responsibility of > the programming aspects of the project so that he could focus on the > design. In recent weeks I have found that I am not logging a full > 40-hour week on my projects, and yet Radiant is not moving forward. > Therefore, I will block out one day a week (Friday) to spend tending to > Radiant. During this day each week, I will be developing the codebase, > addressing tickets and patches, and possibly working on a podcast. I > also intend to have "office hours" on the #radiantcms IRC channel on > FreeNode all day (8AM US Central to about 6PM). > > My hope is that both of these steps will give Radiant the shot in the > arm that it needs. I'd appreciate your thoughts and feedback. > > All the best, > > Sean Cribbs > > P.S. Incidentally, a solution to Josh French's problem with building a > project with the Radiant source in the root could be solved with > git-svn, allowing him to keep up to date with the source of Radiant > while building his own project in the same tree. Git is much more > powerful at managing multiple sources of changes. > _______________________________________________ > Radiant mailing list > Post: [email protected] > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > Sean, I like the effort and seeing that you are motivated to push Radiant forward. Here are my thoughts. I'm not sure how a pull request would be any more effective than a patch on Trac, especially given that Trac is highly visible and accessable by all core members, not just a single person. The best bet would probably be to just do what was suggested and give more people commit access. We can just watch the timeline in Trac to see whats going in, and if regressions are a concern, we should be able to set up CruiseControl.rb to watch for test failures. Perhaps we should also explore a policy or vetting process to get extensions into / out of the Radiant svn tree, especially if there are going to be a lot more developers pitching in. Of course, just leaving it open could be nice as well, since then it becomes easier to maintain and contribute to extensions, and we might not see multiple extensions that just perform a single task (Reorder / Drag and Drop Reorder - Virtual Domains / Multi Site). For my part, speaking as someone who took over maintainership of an abandoned extension and accepted patches through email, I think I'd like to see it more open, even if it does get a bit crowded and some of the extensions fall into disrepair, because it would be easier for someone to pick them up again, and patches could be managed in Trac. Thanks for all your work, -todd[1] _______________________________________________ Radiant mailing list Post: [email protected] Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
