Re: Discussion about the OpenGroupware.org project and OGO

On 25.03.2004, at 21:40, Michael Brown wrote:
> Where I think people may be getting a little frustrated, is that there 
> doesn't appear to be any dates, timelines or milestones around when 
> OGO goes 1.0.  Helge has said, much like the Debian folks, "when it's 
> ready".

No, this is not really true. I consider OGo sources itself ready. What 
I said is that we get OGo 1.0 once we find _time_ to setup the 1.0 
process. This is quite some work and unfortunately needs to be done 
mostly by core staff which is still quite busy in the moment.

I also mentioned before that our "wishdate" for 1.0 is LinuxTag 2004, 
but this is really a matter of available time. We may or may not manage 
to hit that date.

> There's nothing wrong with that; its just that it's not what these 
> excited people want to hear.  I know the project is in it's infancy, 
> and is going through growing pains right now, but newcomers may not 
> know that yet.

I don't think so. The project is overall stable, it "just" needs a 
release. This is far from impossible, its just a certain amount of 
work.

> How is the project going to be managed, and how will
> goals, milestones, deliverables and targets be decided
> upon? (Process, teams, etc.)
>
> What will define 1.0? (Features, functionality, docs,
> support, etc.)

We have a core group of people which are considered the "OGo project 
management". This includes first time contributors like Chris, Kelley, 
Olivier, Frank and of course myself.
For 1.0 this group will present a plan/roadmap for discussion and 
implement that. When? When its ready ;-)

I would like to ask people to wait for this until it is ready.

> What bugs HAVE to be fixed before 1.0 can happen
> (gating issues)?

Yes, this is an important issue which needs to be discussed.

> What features MUST be complete before 1.0 can happen,
> and how do those features get "voted on" or otherwise
> decided upon?

Yes, must be part of a plan.

> How can the COMMUNITY best contribute to make all of
> that happen?

We are going to have RC's and IMHO it would be a task of the community 
to ensure the quality of that, that is, testing testing testing. 
Reporting bugs, verifying bugs etc.

> How can we best recruit people to work on the project?
>  (I've been browsing through bugzilla, and the list of
> enhancement requests just keeps on growing...)

This is different to a growing "buglist", enhancement requests are not 
a bad thing and a growing list of them is certainly not a bad thing. 
Whether enhancement requests are implemented are really dependend on 
the individual contributors or sponsors and can't be forced upon by the 
OGo community.

For example the SKYRIX 5 developers have a completely different, 
customer oriented feature roadmap. This roadmap will match 80% of the 
time, but it won't in some aspects (for example multi language isn't 
important for SKYRIX 5 nor are obscure platforms).

> How can we avoid burning out our key developers? (or
> "pissing them off" so they don't want to play here any
> more ;-)

Send them money ;-) I know this is boring and greedy, but this is the 
best way to free people from other paid work and allow them to place 
time on community wishes.

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss