Joerg Barfurth wrote:
If people really find something they can't live with they can use use our processes to get obstacles removed (like the Community Council or the Engineering steering comittee). But of course, as in any OSS project, if you can't live with project policies, you have to bite the bullet and leave or fork.
Or change the polices :-)
We should make an effort to foster an encouraging environment that attracts contributors. I know it's not hard, and I want to say thank you for all that you've done. I realize that discussing things on mailing lists instead of the more convenient face to face meetings is not an easy change. An open source, "community driven" project is very different from the way a company works. It is important that we (the volunteers) (1) recognize this, (2) appreciate the effort put in by Sun's team and also (3) create an atmosphere that is welcomming to Sun's team, and make "community work" easier.
Joerg, do you have any ideas for making development more attractive? What do you think of the "testing branch" idea? Could it be done? Here's a related thought: If we had a "testing" branch like that, volunteers could contribute macros to add some features. For example, remember the word count macro? I understand that it was a "feature" and so it wouldn't go in the "stable" branch. But it could well go in a "testing" branch, for example.
I think this would be an example of how we can alter the project procedures a bit to make it a more welcomming place for "community".
I'd be grateful for your thoughts on this.
Cheers, Daniel.
-- Senior Representative Digital Distribution Global Training Services Pty. Ltd. Premier OpenOffice.org and StarOffice Online Training providers http://www.digitaldistribution.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
