Dear ReactOS members,
Following the advice of vicmarcal, I would like to herewith kindly propose a topic for discussion at the next ReactOS meeting (whenever it is scheduled):
I. Authorisation
The question is how a person shall be empowered to act or speak for ReactOS, to what degree in what way, with what binding effect and for what area; as well, how such powers can be transferred and withdrawn. The scope shall at least cover all NON-TECHNICAL aspects of ReactOS.
The motive for this proposal is this:
1. You have a lot of people who would like to help SOMEHOW, but not in a technical manner. Many people have superior talents though not in the area of software development; you have brilliant marketing people, economists, artists, lawyers etc. out there, yet so far you lack any organised way to tie them efficiently into the project. (You, being developers, of course know how to tie in developers; but that is exactly what I am NOT talking about.) Figure the people who neither wish to develop, nor wish to test, nor wish to translate... but would not mind to order 200 pens and distribute them to IT students while giving out some juice or something; basically stuff that someone may do for 100 EUR or less, but which, if done by 20-50 people over 5 years, may start to have an effect.
2. We are talking about NON-TECHNICAL aspects. You have a working system for development, there is no need to mess it up and this proposal would wind up in a fruitless and infinite discussion. I propose to therefore not include development into this.
The proposal may also be, of course, declined - especially if you prefer to remain small for the time being. But that, just like the alternative of allowing such help, should be a clear decision.
II. Organisation
Should the authorisation idea not be discussible or decidable at the time being, i.e. if there are too many open questions and you can say neither "yes" nor "no", then I propose alternatively to discuss organisation: WHO may decide WHAT under what circumstances and with what effect; and especially, what is to be done if people dissent. - Because the above is not a big deal, and if you cannot decide on the above, then chances are that you may wish to streamline your decision-making process.
A few points to consider:
- Is it a more "democratic" system (broader consent, but sluggish and often without clear direction) or a more "dictatorial" system (faster and clearer decisions, but maybe at times against majoritary sentiments; the dictators may rotate, e.g. you are always dictator for e.g. one calendar month, then comes the next person - maybe you apply the dictatorial principle only for the everyday stuff, while big stuff needs common approval - which is not unlike to how a government or a company works);
- What is needed to meet what decisions (e.g., BIG decisions, as such involving entering into legally binding agreements with other entities in the name of ReactOS will need more thorough consideration than inviting to a pizza & coke event to promote ReactOS; you may set up rules on quorums and majorities);
- What means shall be there to perform tasks - and yes, the money question will come up here. (Even the pizza & coke event needs some money.) You could say, up to 5% of some certain fonds (to be filled by donations) may be used by ... for the purposes of ... - You could also say, the person in charge of ... may do with his OWN money whatever he likes, as long as he does not ... (please fill in as considered proper).
These are just my humble proposals and it is up to you to decide on whether and how they might be implemented or further explored. If you have any ideas to improve or change them, please do not hesitate to comment accordingly.
Kind regards,
Aeneas
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
I have been following ROS for a while now and I see a few issues that
need to be solved before it can grow.
1. Setup a PR group: This group will advertise, recruit and get
supporters. It will be the job to spread word of ros, they will first
attempt to recruit developers until a time that ros is out of alpha
and can be use for daily use. They will also look for funding for ros
by contacting possible donators. This group will need to be tiered so
that we can organize what we need to do and when and have the leg
workers able to carry it out.
2. Delegation / authority: We need to setup a bit of authority
especially when it comes to the PR group. These people will be able to
delegate time sensitive/ priority jobs to personal and have a way of
communication between PR and Devs.
3. Website: The website needs to be updated (Which I have been told is
in the works) The PR’s first goal should be finding some people able
to manage that. They will need to have a template of what has
currently been done and a design of what needs to be completed.
4. Project Information for new devs: We need to update the list of
things that are “TODO” , the best list I have seen for something like
this is... http://www.reactos.org/wiki/Google_Summer_of_Code_2011_Ideas
This will give developers who check out the project a clear goal that
they might want to pick up. This can be bundled with the way GSoC has
a mentor program and have available mentors if someone needed more
guidance.
