# Moving forward more quickly **URL:** \ **Category:** Radiant CMS\ **Created:** [March 31, 2008, 7:16pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457 "2008-03-31T19:16:40Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 7:16pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/1 "2008-03-31T19:16:40Z")
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](http://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](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 L. 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 C. P.S. Incidentally, a solution to Josh F.'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. ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 7:59pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/2 "2008-03-31T19:59:15Z")
+1 for github. I recently decided on github for my fledgling project[1] for the same reasons that you mentioned. Its definitely a superior solution for encouraging patches. Patches don’t get lost or forgotten this way. It also has the benefit of allowing the community to review a more complicated patch/feature in its entirety. Just clone the fork and try it out on your box. This also has promise for Radiant extensions. Its a low cost way for people to throw up the work they’ve done. Someone else might just want to finish off one of my half-assed extensions some day. It should also be possible to build an “official” extensions project of officially sanctioned and tested extensions that are pulled in from individual development efforts. Good luck with this new approach. Look for my fork as soon as I have something to contribute 😉 Sean Schofield [1] [http://github.com/schof/spree/tree/master](http://github.com/schof/spree/tree/master) ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 8:09pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/3 "2008-03-31T20:09:26Z")
+1 For GitHub and +1 for this initiative. I hope I can add value. ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 8:01pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/4 "2008-03-31T20:01:02Z")
On Mon, Mar 31, 2008 at 5:15 PM, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 1. Small changes often encompass some of the greatest effort. One > To this end, I want to attempt an experiment. The first step is that I > Although we like to pride ourselves on our specs, the coverage in > Radiant. During this day each week, I will be developing the codebase, 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] ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 8:10pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/5 "2008-03-31T20:10:01Z")
> 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. That’s why I was calling it an experiment. I’m not sure how the community will develop once this is in place. I also haven’t decided what process we will use to grant commit access. Most of all I want to foster is contribution so that the project can move forward. I think we can figure out the details along the way. Sean ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 9:54pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/6 "2008-03-31T21:54:00Z")
[snip] > 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. [/snip] Git is superior to SVN in the same way that SVN is superior to CVS. So moving to git in general is probably in the best interests of the project. One key way in which git is superior to SVN is the ease with which you can contribute complex patches (such as new features or a major refactoring) and have everyone be able to easily try them out with a simple clone operation on the forked repository. Github specifically allows you watch projects via RSS feeds so that’s a nice bonus as well. No need to have a special email list for commits. > -todd[1] sean schofield ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 9:49pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/7 "2008-03-31T21:49:48Z")
Hey Sean, I like the idea. I was at the conference and Evan’s talk got me thinking about some of the same things. The rest of the conference was killer and Confreaks will be putting up more of the talks so check those out too. Another side note, there was quite the git lovefest going on there. I do believe moving to a git approach will make it easier to contribute. I look forward to giving it a try. Cheers, Marty ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 9:56pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/8 "2008-03-31T21:56:56Z")
One really appealing idea in the git process is the ability to proceed down multiple paths simultaneously (more easily than SVN). I think this will speed development by allowing contributors to work on the parts that really interest them while still maintaining a sensible gem release. For example, one could create a branch for the REST refactorings and start working on them without disturbing the master branch that will be used to release 0.6.5. Sean ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 9:58pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/9 "2008-03-31T21:58:47Z")
> That’s why I was calling it an experiment. I’m not sure how the > community will develop once this is in place. I also haven’t decided > what process we will use to grant commit access. Most of all I want to > foster is contribution so that the project can move forward. I think we > can figure out the details along the way. The beauty of Github is that this is of little consequence. You can have a single person (you) as a gatekeeper on the master repo on github. You can use whatever formal or informal process you want to determine when its appropriate to pull something into the master branch. Maybe you have a few people with this access for redundancy but I think github removes some of the controversy over who has commit rights. Everyone can commit. The people who do all of the work maintaining Radiant (such as yourself) can exercise quality control and the community as a whole decides what should go in. ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 31, 2008, 10:29pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/10 "2008-03-31T22:29:11Z")
On Mon, Mar 31, 2008 at 1:55 PM, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > One really appealing idea in the git process is the ability to proceed > down multiple paths simultaneously (more easily than SVN). I think this > will speed development by allowing contributors to work on the parts > that really interest them while still maintaining a sensible gem > release. For example, one could create a branch for the REST > refactorings and start working on them without disturbing the master > branch that will be used to release 0.6.5. I agree. A few months ago people asked at the Boulder Ruby group what was the going thought on Git. I hadn’t used it yet so I didn’t really have anything to add to it. At the time I didn’t see any big motivation to move to it though it did sound like an improvement over svn. However, after talking with more people and seeing how people are using it in the wild, I’m starting to come around. I think that git is a superior process in the ease of trying something new and being able to keep your fork current. Doing that in svn does seem painful and quite frankly I wouldn’t even try to. I think Github’s features make this even better. Cheers, Marty ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [April 1, 2008, 4:20am UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/11 "2008-04-01T04:20:38Z")
On Mar 31, 2008, at 1:15 PM, Sean C. wrote: > always > been wanting to build. This sounds like a fun experiment. Perhaps something should be said about this on the development home page. A couple things to note. While I agree that I would love to see development on Radiant moving forward at a faster pace, I think it’s important to keep the ideals of the project in focus. To that end, here are a couple of things I think we should keep in mind when applying patches to the Radiant code base: 1. Code is a liability. It is important to realize that every feature we add increases the complexity of the code base. The added complexity costs us exponentially over time to maintain. To this end we should do everything in our power to keep the code base lean. Removing extraneous code should be a sport. 2. Features should only be added that are generally useful to the community. 3. We need to be absolutely brutal about rejecting feature proposals that do not live up points 1 and 2. Extensions are the perfect place to work out pet peeves. 4. Radiant is primarily designed for static Web sites (that is, sites that are not dynamically generated). It is not, and should not become, portal software. 5. Clarity and beauty should be valued over brevity. I would like to especially encourage people to submit patches that “clean up” the code base. > That said, I’d like our basic ground-rule to > apply, namely, that any patch you submit should have adequate specs. Amen to that. > 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). Three cheers for Sean! He is by far the most frequent committer of any of the core team members (including myself). I can’t believe he is planning to devote even more time to the project. He deserves a medal. – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [April 2, 2008, 2:19pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/12 "2008-04-02T14:19:17Z")
> It seems like Radiant pages are dynamically generated. The content is > moved out of html pages and stored in the database and then generated > with layouts, pages, and snippets. It seems like a lot of the sites > listed as using Radiant are “portal” sites. Could someone clarify this? Yes, pages are “dynamically generated” in some senses. However, their primary use case is not the aggregation of data from multiple local or remote modules which could possibly be manipulated by site visitors. John’s point is that Radiant is for “publishing” in a very planned sense, not for “collaboration” or “community portals”. Sean ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [April 2, 2008, 9:52pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/13 "2008-04-02T21:52:14Z")
[snip] > I’d like to re-open that issue because i find a google group much more > usable than a maillist… > personally i prefer to follow the list through the group, and find it > annoying that i cannot reply there. +1 for google groups. You can still use google groups like an email list but it gives you the option of doing your occasional posting without having to follow the daily emails in your inbox (or deactivate and reactivate filters.) Another benefit is the great search capability within the forum. Finally, it appears that google group postings are more easily found doing a standard google search. > Benny Sean Schofield ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [April 2, 2008, 11:13pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/14 "2008-04-02T23:13:33Z")
IIRC, the reasoning for not moving the list was the extensive archives that cannot be ported to Google G., and that we would potentially lose a bunch of subscribers. The dev mailing list went there either because it was brand new, or because there was not enough in the archives to warrant it. Can someone look into information about migrating the archives? If it’s possible now, that could reduce the pain of migration. Sean ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [April 1, 2008, 10:16pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/15 "2008-04-01T22:16:52Z")
Hi Sean, Great thoughts, and fantastic to hear that you will devote even more time to Radiant. Evan just gave that same speech here at the Ruby Fools 2008 conference in Copenhagen, and you are right: It is quite inspirational. Git seems to be the right choice for opening up the contribution process. Now that Rails is also moving to git, it will gently push a lot of people in the community to install and learn to use git. Cheers, Casper F. ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [April 2, 2008, 11:51pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/16 "2008-04-02T23:51:51Z")
From what I found there is still no way to transfer archives to google groups. (Interestingly, you can mirror another list in google groups.) See [http://groups.google.com/support/bin/answer.py?answer=46387&topic=9249](http://groups.google.com/support/bin/answer.py?answer=46387&topic=9249) . Most other lists I found that have gone to groups have a separate static archive of all of their older postings. Matt Freels removed\_email\_address@domain.invalid > **[Matt Freels](https://matt.freels.name/)** > > Follow @mf on Micro.blog. ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [April 2, 2008, 11:55pm UTC](https://www.ruby-forum.com/t/moving-forward-more-quickly/133457/17 "2008-04-02T23:55:59Z")
Thanks to Nick Plante who submitted the first pull-request and patch via GitHub. Keep the good work! Sean