@jason

> What is the definition of a contributor?

OSE defines it as someone who completes a task associated with an OSE project as documented on the Pivotal project tracking application.  Since you have to be invited to participate in a Pivotal project, there is an initial period of negotiation between you and the project leader.  While this does create a barrier to entry in an OSE project, it's necessary, to some degree.  Speaking as one of OSE's few project managers, I want people on my team who will make a serious contribution.  I don't want someone who will constantly complain about poor decisions, etc.  Instead, I want someone who will intelligently discuss project plans and make positive suggestions for how we might improve things and then help me make it happen.

It has been decided that the OSE project forums will be tools dedicated to the projects themselves.  As such, they will be restricted to Contributors.  Others will still be able to view the conversation.  If they truly have something to say or contribute, they have two options open to them:  make a post in the General Discussion forum, or send email to the project manager.  Using either approach, HOW you make the suggestion will be as important as WHAT you suggest.

@DavidIAM

>  the importance of having tools to work with for collaboration that are
so much a part of the process that they are ALWAYS up to date.

That's the goal, though it is a work in progress, naturally.  Yes, the project forums are more segregated than exclusive.  Hopefully, this will increase the signal to noise ratio in the project forums, which will in turn encourage those who should use it.  If you (or anyone else) truly wants to participate in an OSE project forum, then become a contributor.  OSE is a meritocracy - which means that people are given abilities according to their merits - largely measured by what they contribute.  Complaining, whining, and personal attacks are a negative contribution that we really don't want or need (not that I'm saying that you do this).

For more information, have a look at Forum Policy (Link updated - Elifarley).  It was substantially updated this morning.

Thanks for the explanation mjn, as well as the update to the wiki. It is good to point out similarities with other successful open source project structures, for those of us who aren't familiar with the process. As long as we are following a standardized process, I'm much more comfortable with it.

I would like to challenge the team, however, as we move forward, to consider what differences there might be between an open source software project and an open source hardware project. Some obvious differences would be that anyone can download code and compile it, relatively easily. However, to get a piece of hardware built and running is a completely different matter. Also, the "interfaces" between hardware can be almost trivial - the interface to a renewable power source might be the ability to charge 12 volt batteries, for example.

My main point is that, I agree with you, the project forums should be tightly controlled to create a structured and dynamic team. However, grouping the specific project implementation and the technology being implemented in the same forum could be a bad thing. For example, lets say the tool needed is a windmill. There may be a dozen different viable options for a windmill, that have different pros and cons. If one team "has the windmill" and exclusive access to its associated technology forums, it is difficult to have on-going discussions about different windmill technologies, open sourcing someone else's windmill designs, or a guy making his own version and updating it. In the software world, you generally don't have this problem - you've got a tightly managed piece of code that is THE code. Everyone downloads it, everyone uses it, its not perfect but it is continually being "maintained". You aren't constantly thinking about better ways to architect it because that would take man months or years. With hardware, every time you built one you are literally building it with your own hands. Its not problematic to have a different version - all it has to do is charge the batteries.

My solution would be that perhaps the function should be separated from the implementation. The implementation is the tightly managed project you talk about, the larger technology/function discussion should be an open, ongoing discussion, in a separate subforum. Perhaps the team will come up with a different solution for the differences described above; I just want these things to be brought to everyone's attention.

Perhaps I'm saying the same things as Fabio but in a much less concise way.