-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Royce Mitchell III Sent: 27. november 2005 20:02 To: ReactOS Development List Subject: Re: [ros-dev] [Vote] Top-level source header
Casper Hornstrup wrote:
By making project rules we can better avoid the "I'll rewrite it this way because my way is better" class of changes. Without project rules, it is the last one to commit that "wins".
I don't disagree with this, but as I stated before this is an open source unpaid project, so we should only have so many rules as are strictly necessary. We should take great care about the rules we create.
I agree, but I trust people to use their best judgement. If 90% vote for something which I think is crazy, who am I to say this shouldn't be how the project will do it?
Too many rules - especially frivolous ones, and we'll drive potential developers and even existing developers away.
I could say the same about too few rules. Remember that what one person does, affects the other persons on the project. I suppose I would like ReactOS to be somewhere on the middle of this line.
No rules Many rules <-----------------------------------------------------------> Chaos/inconsistency order/consistency
E.g. having order/consistency where is helps the group function well and help the group create a better product. I know ReactOS is about having fun, but I don't think that not being able to do whatever you feel like with regard to the project implies no fun. Certainly being in the chaos/inconsistency state (we've been there) won't create a happy team. I remember times when ReactOS often couldn't be built or booted for weeks at a time. In the early days, I just spent my time elsewhere when that happened. ReactOS wasn't useful anyway.
I recently joined a 15 person team who were working on some project. This project was close to the no rules/chaos end of that line. Of course the project was more than 100% over budget and half of the team worked 60-70 hours/week for two months. They were of course unhappy about that, but they really wanted to have this product ready for their customer. Nobody likes to fail. For those of you who are interested in numbers, that is a burn-rate of approx. 700 hours/week. I'll leave it as an exercise to the reader to calculate their salary per week ;-) Hint: additional hours over 37 hours/week pays 100% extra.
I see similarity in the ReactOS project. I see many desperately waiting for that 1.0 release. Now since nobody is paid to work on ReactOS, the project can't go 100% over budget. We can however spend twice or more as many hours getting there, depending on how we choose to develop ReactOS. So instead of reaching 1.0 in 2010 we have to wait until 2022. I'm not a patient person.
Furthermore, this vote seems to have started in part because you complained that a header copied from another file didn't get updated properly. I can only assume that means you intend to have removed parts of the headers that are in excess of the agreed-upon header in the vote.
Well, the voting is about what the standard should be (e.g. for new files). It doesn't specify anything about what to do with the existing headers. They could be replaced over time for instance.
That's what comments are for.
As I just stated, you were complaining about comments in the header about the name of the file that you felt shouldn't be there. Where do we draw this line of what's an allowed comment?
I argumented that the contents of the FILE fields in the headers tend to become wrong and thus useless over time. I can point you to at least four new files added this week for which this is true. I can point you to another set of files where the PURPOSE and PROGRAMMER fields states "Unknown" just because "something should be there". The vote is about how the header should look like and there were three suggestions. We have no rules for comments so you can put anything you feel like in a comment below the header. If you put the name of the file in a comment in the file, then fine. I will however still argument that they become wrong over time.
That you or someone else don't like a change shouldn't prevent someone else from trying to make that change. Which person or persons should decide which changes shouldn't be allowed to be proposed? If you don't like what someone else proposes, then you can use your right to vote to stop that change within the project.
Even this is a gray area, because if someone is making changes to an area nobody else wants to touch... well... maybe I don't like it, but if I'm not willing to fix a perceived problem but someone else is, then how much right do I have to complain.... it's like the story of the little red hen: nobody wanted to help her bake the bread, but they all wanted to eat it. All I'm saying is that we should try to limit our complaints about other people's changes just because we don't "like" them. We're never going to all agree completely on how things should be done. We need to agree to disagree and only invoke this kind of policy-setting when it's really important. I think at a minimum we need to more carefully word the proposals for the top-level source header issue here
- in order to solve the problem without unnecessarily constraining
freedom to develop in each of our own styles.
He has every right. If not, who decides that he hasn't the right? He may not have good reasons to complain, and may just be annoying to other people, but that's another issue.
Casper