Moving forward more quickly
Sean Cribbs
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.
Nick Plante
Wow, great writeup, and I couldn't agree more.
I think moving to github and encouraging forks will really help move
things forward as well. It's great to see that the growing git adoption
rate is making 'fork' sound like less and less of a dirty word as time
goes on. Experimentation is (almost) always good.
Glad to see that the core extensions are up there as well. Now I can fork
the multi-site extension and add my changes in. For great justice! :)
Best,
..nap
PS Thanks to all the Radiant core team and everyone else who has
contributed up to this point, as well. Although there are always design
decisions that I'll disagree with in almost any project, Radiant is a
pleasure to use and extend.
Nick Plante
Radiant on github. It's available at:
http://github.com/zapnap/radiant/tree/master/extensions/multi_site
This altered version extends the original work allowing you to scope
users' administrative capabilities to a particular site. Those users
cannot see, access, or alter any sites that do not belong to them.
Admin and developer users can continue to access and edit pages belonging
to any site, of course.
In addition to scoping sites/pages to users, you can also optionally scope
layouts to sites, so that a particular layout, like "FooLayout" is not
accessible to the user who is bound to the Bar site/page root. Snippets
are not limited in this way, but note that access to snippets has been
DISABLED For regular (non-admin/dev) users. This is probably the biggest
compromise.
Anyway, this is just some stuff I've been working on here, extracted from
a client project. Comments and suggestions are of course welcome. I'm
assuming that this isn't a patch candidate (or maybe it is?) for the core
extension, but I could spin it out into a separate extension
("scoped_multi_site" or whatever) if there's interest.
I've also been thinking that it might be cleaner to scope access based on
the host used to access the admin area (foo.mysite.com vs bar.mysite.com)
unless the user is an admin or a dev.
Best,
..nap.