Hi! There are nice points in your suggestions.Our internal organization has been improved thanks to the regular monthly meetings.However these regular meetings are new and a lot of "needs" must be covered. The first regular meetings have been development focused(cmake adoption,gsoc,arwinss,..)but there are also some little winks to the ReactOS community(new website revamp discussion,ReactOS meeting minutes,and some tries of ReactOS Collaborative testing).Imo we need first(#1) to fix/solve/improve our internal development(reducing potential dramas,problems and deciding our objectives),then(#2) the Community(improving our communication with the Forum users,improving their sense of community feeling,and helping them to help us) and in a third step comes the PRing which means a solid structure to promote ReactOS. If we begin PRing without having a stable internal organization(#1) or a stable community(#2),then the newcomers wont stay long among us.Also coordinating all of them would be almost impossible to handle :) We are in the middle of step #1.Hope we can move soon to #2 thanks to suggestions as yours. After the release is done(hope It'll be during the following weeks)I'll try to rise attention to this email :) Again,before moving to fix #3 we should considering creating a structure to fix #2 first. Best regards :)
Enviado desde mi iPhone El 29/08/2011, a las 16:47, "Michael Klos" <[email protected]> escribió: > Remove me from your e-mail list. > > On 8/26/2011 1:44 PM, Nino on NetBSD 5.0.1 wrote: >> 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 > > _______________________________________________ > Ros-general mailing list > [email protected] > http://www.reactos.org/mailman/listinfo/ros-general _______________________________________________ Ros-general mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-general
