[development] #drupal and #drupal-contribute split (Was: Re:Proposal: Move all dev support off this list to newStackExchange site)

[Arlin Sandbulte]

Overall, I think this is a great and relevant discussion, but in may ways,
the problems discussed here are just a sign up 'growing pains' or simply
'growing up.' (and I don't mean that in either a good or bad way.  That is
just the way it is.)

I have a GREAT, close family.  Growing up, we ALL spent Christmas Day at
Grandma & Grandpa's house... Grandma, Grandpa, their 7 kids & spouses, plus
some 40 of us grandchildren.  ~50 people in one small house....AWESOME!  We
all exchanged gifts, ate too much food, and had LOTS of fun.  Those were the
good old days.
Now, my generation has grown up.  We've gotten married.  We have kids of our
own.  Grandma and Grandpa can't handle everyone for Christmas any more.  We
still have Christmas together at a large hall, but not everyone can make it
for obvious reasons.
It's just not the same not having Christmas at Grandpa & Grandma's house.
Every one of us would love nothing more than to go back to those 'good old
days.'

Now, in Drupal, we find ourselves looking back at D4, D5, & even D6 and we
want to hang on the those 'good old days.'  Nothing wrong with that.  We
NEED to hold on to what made/makes Drupal great.  But, we can't get stuck in
the past either.  We must look forward & 'flow with the times.'
Dries is trying to address this same issue in D8 with his initiative
leaders.

I totally understand both sides of this discussion (are there two
sides?)...
I am only a weekend warrior with a totally unrelated day job.  I remember
one of the first times I logged onto IRC, I asked a question, and webchick
herself actually answered!  That was VERY encouraging to me, and might be
one of the reasons I stayed and am now trying to learn more.
I am not a coder or developer, but I do try to contribute.  In my case, I
have chosen to focus on the Date and Calendar modules, where I spend a lot
of time in the issue queues.  I even have a certified to rock score of 7.
That's the same as rfay, and I would not know the first thing about building
a module. (although Karen has graciously allowed me to become co-maintainer,
thanks Karen!).... maybe the certifiedtorock score algorithm needs some
tweaking....

I do think there needs to be some sort of hierarchical organization for
support channels, but at the same time, the 'elite' need to actively foster
and teach the next generation of contributors.
I actually think merlin has realized this and is doing a pretty good job.
Views is not just a one-man show.  Merlin has a team of contributors that he
can work closely with while they help bride the gap... just as Dries is
planning for D8.  The Views Bug Squad, and merlin's other calls for
contributors are a great example of this.  That does not mean that Dries or
Earl are inaccessible, it just means they have some high-level help and they
are fostering that help.

Going back to my family analogy, I think it would be useful to follow the
'elder model' instead of the 'elite model.'  In society, elders reach a
point where they no longer do any work, but they are invaluable in leading,
mentoring, and advising those who ARE doing the grunt work.  Elders can also
take a more active role in babysitting the kids.

I don't have any answers to the immediate questions here (splitting dev &
general groups).
None of this is easy.  Managing a project (or sub-project) is A LOT harder
than just doing it yourself in a bubble.  But, encouraging and helping and
fostering a more diverse pool of contributions WILL BE worth the extra
effort.

I will end with one last example:
Rick Warren started Saddleback church in his home with one other family.
Today, Saddleback is one of the largest mega-churches in the US with
multiple physical & online campuses and a staff to match.  Rick has said
that the growth and his resulting 'distance' from the individuals was and is
one of the hardest things he has ever done...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110319/3ba21fac/attachment.html