[openbeos-cdt] Re: CDT regrouping: why and how?
- From: Stephan Assmus <superstippi@xxxxxx>
- To: openbeos-cdt@xxxxxxxxxxxxx
- Date: Fri, 13 Nov 2009 11:23:56 +0100
Hi,
On 2009-11-06 at 10:47:50 [+0100], Eddy Groen <eddyspeeder@xxxxxxxxx> wrote:
> Question: what should be our first few steps to really make sure the CDT
> does take off?
Your first tasks is to understand what works and what doesn't work in a
volunteer driven open source project. To me it seems you are approaching
this somewhat like someone running a company with people working on what
they are told to work on for money.
The CDT can be successful. Over the years, we have had many elaborate
discussions about future UI functionality, features and design. Within
those discussions, some insanely useful ideas have been expressed. If the
CDT has discussions like this here on this mailing list, it will just be
that: Yet more nice dicussions with useful ideas, just on it's own
dedicated mailing list. Since it's basically the same thing, not anything
more will come of it than before.
What needs to happen is that the CDT takes it one step further. After
discussions have happened, someone needs to put the cool ideas into a
specification. Depending on the complexity of the item being discussed,
this could either mean a simple Trac enhencement ticket, or an elaborate
wiki page, preferrably also on Trac. What communication means the CDT
choses to produce specifications is irrelevant, as long as the end result
are developer visible, ready to be picked, thought-through (!) and
elaborately explained, specifications at a central location.
The CDT will gain credibility with the developers *only* by producing
quality specifications, ready to be picked for implementation. Ready to be
pointed at when someone comes along looking for something to do. You need
to realize that by doing what I outlined above, some people have already
been successful in being influential in the CDT domain. For example,
Waldemar Kornewald produced specifications (although in retrospect, they
have been way to brief), and Humdinger produced some nice pages for CDT
domain change suggestions. This is something that would work, provided the
CDT understands this and is actually able to do this, rather than everyone
just expressing what they think should/must be done, like I am doing here.
:-)
What will definitely not work, is if the CDT is "assigned" responsibility
and decision making power. There is no such thing in the Haiku project, but
people joining us frequently fail to understand this. Everyone who has ever
gained any influence in the project has done so by doing work, or providing
pieces of work ready to be used by others. The door is wide open for a CDT
to achieve the same, but it won't be because someone "influential" says the
CDT is now tasked with such and such.
Find something you want to improve. Come up with an initial idea. Discuss
it by any means necessary. But then, do the extra work of putting it into a
specification that shows how something works and explains the
thoughts/reasons behind it. Put it somewhere visible and start pointing
people at it. This is your route to success. Even a single person can do
(and has done) this and gained influence accordingly. You don't even need a
team hierarchy, as long as a single one of you can motivate himselves to
digest information and put it on a Wiki page.
Best regards,
-Stephan
Other related posts:
