Moving forward more quickly

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 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.

+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 :wink:

Sean Schofield

[1] http://github.com/schof/spree/tree/master

+1 For GitHub and +1 for this initiative.

I hope I can add value.

On Mon, Mar 31, 2008 at 5:15 PM, Sean C. [email protected]
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]

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

[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

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

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

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.

On Mon, Mar 31, 2008 at 1:55 PM, Sean C. [email protected]
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

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

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

[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

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

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.

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
. Most other lists I found that have gone to groups have a separate
static archive of all of their older postings.

Matt Freels
[email protected]
http://matt.freels.name

Thanks to Nick Plante who submitted the first pull-request and patch via
GitHub. Keep the good work!

Sean

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs