[openbeos] Re: RFC archieve and public access
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx, glasselevator@xxxxxxxxxxxx
- Date: Thu, 28 Feb 2002 22:09:59 EST (-0500)
> I want to take this point by point:
>
> > [Zenja Solaja] Hi everyone. I believe that we urgently need to
> >solve a very serious problem - the archieving of great ideas
> > floating around
> >GE and OBOS lists. This issue was brought up in another thread and
> > I'd like
> >to move it to its own thread.
> >
> > What I'm proposing is:
> >
> > 1. We establish a public repository (the GE or OBOS website) where
> >we publish a set of RFC documents.
>
> That is supposed to be what GE is.
And *is* what GE is. In fact, this functionality already exists on the
GE website and has several RFCs.
> > 2. Each RFC would address a certain domain, ie a FileSystem layout
> >RFC, a Deskbar GUI RFC, Window Border RFC etc.
>
> Fine.
I would expect that no RFC would address multiple domains. But
competing RFCs should certainly be allowed.
> > 5. We'd limit discussion to one item at a time until a consensus is
> >met. We would cycle through the entire RFC twice.
>
> Whoa.
>
> > 6. A greater than 2/3 majority is essential (>66%). Therefore,
> >quorum is at least 4 people voting. Here are some illustrative
> > numbers to
> >accept an item: 3/4 (75%), 4/5 (80%), 5/6 (83%), 5/7 (71%), 6/8
> > (75%) etc.
> >Notice how 4/6 doesn't pass the >2/3 barrier. To loby for an item,
> > simply
> >get more supporters to vote for it.
>
> I don't think so.
These two points scare me, too. (1) Where do these numbers come from? 4
people? There are rather more than that around, I think. (2) I am
definitely against restricting general discussion. The existing RFCs
are the *product* of discussion, not the antecedant of it.
> > 7. Once the community agrees on a RFC, it becomes a SRS (system
> >requirements specification). Ambitious developers can now tackle a
> > project
> >of their choosing.
>
> Nope.
This sounds good, but won't work. Operating systems (as Michael
addresses in his next point) don't evolve piecemeal. We need to build
on existing things first. For example, we will need a UI before we do a
media kit, and we will need a kernel before we do anything.
> > Comments from webdevelopers (people responsible for implementing
> >this system), administrators, and everyone else.
> >
> > <PS - continue discussion on GE mailing list (Reply to:
> >glasselevator@xxxxxxxxxxxx)>
>
> I want to keep this on the general list, because there is some
> confusion on this point.
> GE has been and is all about collecting new ideas for R2. Collection,
> discussion, organization.
> Not building. Not voting, not deciding.
A couple points here. I think we *should* decide things. Recomendations
should be finalized for coding when the appropriate time comes. *But*
this will likely happen by consensus or convergence, without voting.
Take the UI debate raging on the GE list now. Many people started out
with *wildly* different points of view, and now seem to be closer and
closer to agreeing with each other. This happened without votes or
really even formal discussion. This is, as far as I'm concerned, the
way GE should work.
On coding: Coding will not be allowed until we're a *lot* further into
this except for proof of concept coding. This is for several reasons:
(1) We will be building off OBOS R1 code in most cases. We can't do
that until it exists. No matter what wild and wacky design is chosen,
certain things will be kept, and since it is a next version of BeOS,
it's not going to be so wild and wacky as all that.
(2) There is no point coding until *what* we're coding has been
decided.
(3) As to proof of concept coding: If someone asks, "Is this even
possible?", we should check. This is the way to do it. Further, if we
are producing coding style guidelines or general API specs, it's useful
to have what you mean illustrated, and to see if it makes coding too
obfuscated.
> First off, there is nothing to build ON. In order to start
> implementing, you would need a finished R1.
> That has yet to happen, unless I missed something.
Agreed.
> Secondly, who votes?
> Personally, I am thinking meritocracy. People who contribute more,
> get more pull. More say.
> That doesn't include JUST code, but people who have written code in a
> particular area should have
> a good amount of say about what they work on.
Most definitely. In a consensus-based environment, this would happen by
default.
> Think about it. You are working on something that is "yours". That
> you have vested heart and soul in.
> And a group of people come along who have never contributed one thing
> to the project and "outvote" you?
> I don't think so. That is not fair to developers, and not fair to the
> community.
Amen, brother!
> I like the idea of collecting good ideas. Be did that all the time.
> Then they decided what was possible, what
> the best approach was and how to do it. Not always the way you might
> like, but you also don't necessarily
> know why, either.
Yes.
-Nathan
--
Fortune Cookie Says:
Krogt, n. (chemical symbol: Kr):
The metallic silver coating found on fast-food game cards.
-- Rich Hall, "Sniglets"
Other related posts:
