27 Nov
2005
27 Nov
'05
9:09 p.m.
-----Original Message-----
From: ros-dev-bounces(a)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:
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?
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. 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? 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.