Subject:
|
Re: Backwards Compatibility (Was Calling all Meta-commands)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 17 Mar 2003 02:02:16 GMT
|
Viewed:
|
1942 times
|
| |
|
|
In lugnet.cad.dev, Kyle McDonald writes:
> Well this was one of the reasons behind my original suggestion.
> (This thread sure did take off while I was away skiing this weekend.)
>
> I suggested that a new meta command group be made today, albeit
> before the creation of a standards body, so that Application
> authors could be free to add/implement whatever they can think of
> in this namespace branch, without using up names that the
> community might want to use for something else later on.
I disagree. Let's stick with the current method of meta-commands until a
standards body officially determines the syntax of future generation
commands. No hold on anything, innovation can continue (just in the same
disorganized fashion it always has), until a definitive decision is reached.
> This would eliniate the suffering, I would think.
>
> Once a new command was announced, it could be discussed by the
> community (or even by a standards board if one existed) and
> possibly promoted (maybe with changes) to be a top-level meta
> command that is officially recognized.
I agree.
I like the idea of a standards body with defined members, either volunteer
or voted in initially, but for a certain term. Right now I favor volunteers
for this body, since I think we'll only have a handful of them. Is there a
magic number of people here... there can't be too many on this board or
nothing will get done, but not too few, we need a good cross-section of the
community's programmers.
I also think it would be great if the community could 'listen in' on a std.
body mailing list -- like receive the mails but not be able to post. Then
broader discussion can take place here on cad.dev, adding to the depth of
the discussion without adding to the noise *inside* the SB. The SB would
then vote on additions/changes to the spec.
My thoughts are kinda blobby right now. I get the feeling I should talk with
a few people and come up with a good, fair method of establishing the SB,
and guidelines for the SB prepetuating itself. As stated elsewhere, I'd like
to help guide this into existance, but not participate on the actual SB.
(Any input on how to do this is appreciated)
Dan wrote:
> > I think this standards body should be compirsed of the people who write the
> > programs. I do NOT think it should be a political body, at all.
>
>
> I'm not sure that alot of this couldn't just be done through
> discussion right here, possibly with some formal voting mechanism
> on ldraw.org.
A formal voting system is needed, I think. Steve and I have discussed this
quite a bit. We need some way to define 'members' and some way for members
to vote.
I DO NOT think just anyone should vote on standards. The members of the SB
should be people who program the various tools. I also strongly recommend
Steve is on the SB, though he probably will want the position himself
anyways. :-)
The reason the SB shouldn't be a free-for-all for anyone to comment on is we
need people with experience programming, and we need a relatively small
(less than 10 for sure) number of people to maintain efficiency and focus. I
am very wary of letting large groups make decisions. Every crowd has a
stupid lining.
So there needs to be a good, solid, fair process to establish the SB, it's
members, guidelines for procedures, and guidelines on how to introduce new
members as other members phase out.
> If a true committee were really needed though, I would think that
> both application and part authors should be included.
Sure. Those would make good conditions for membership.
I'm strongly in favor of a clearly defined committee. I don't think we'll
get very far without one. Allow open discussion, but have actual decisions
made by a specific group focused on the task of maintaining and advancing
the spec.
Case in point - programmers here probably wouldn't want me contributing to
the decision making ;-) But, I'm yakking here anyways. Open discussion by
anyone, actual decisions by people who really know what they're talking about.
Without clearly defined roles and processes for standards, we have chaos.
> If this wide open free-for-all branch of the namespace was
> available to developrs, I'm not sure much 'enforcement' needs
> to be done. I would think that the honor system would work fine
> for the most part, once word got out that all the new commands
> should at least start out in that development area.
I'm in favor of allowing programmers to experiment freely, but then having a
process to submit new meta commands to the board to be ratified as official.
If they aren't ratified, no one says the programmer can't keep using them,
they just aren't a part of the official spec.
No negative enforcement, but positive reinforcement. We encourage people to
submit commands with the aim of them being official, and therefore
distributed to everyone from the spec document. But, we don't chastize
someone, tell them to go away, or otherwise act negaively towards someone
who doesn't do this.
> > I think a list of meta-commands does make sence, so people won't
> > inadvertently step over each other toes. But "regulating" the
> > meta-commands seems like over kill to me.
>
> Regulating it does seem like it might stifle innovation.
> That's the main reason I think that a development 'sandbox'
> namespace might be the best comprimise.
Again -- regulation in the positive, not in the negative. The goal should be
to encourage people to submit their new meta-commands for official adoption
by the SB. We won't tell someone they can't use a meta-command. The honor
system should work, there will be a published list of commands, and
programmers [who are interested in the growth of the system] will not
interfere with those.
-Tim
|
|
Message has 1 Reply:
Message is in Reply To:
154 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
