Subject:
|
Re: Backwards Compatibility (Was Calling all Meta-commands)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 17 Mar 2003 23:02:51 GMT
|
Viewed:
|
2097 times
|
| |
|
|
In lugnet.cad.dev, Kyle McDonald writes:
> Tim Courtney wrote:
> > In lugnet.cad.dev, Kyle McDonald writes:
> > > 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.
>
>
> That's fine also. I was only offering a possible way to avoid
> taking even more useful options away from the standards commitee.
Understood. I think we need to focus on creating legitimacy for making
decisions on standards before actually making decisions on standards. ;-)
> I don't think it would be too much to ask that new commands
> all be prefixed with 'UNOFF' or 'UNOFFICIAL'. It of course
> would be totally on the honor system, which as you've stated
> has worked in the past (.DAT -> .LDR conversion.) and the
> whole 'unofficial' concept even has a parallel in the parts
> releases too.
That's a resonable request. Here's some thoughts -- I think the standards
body will be forming soon, within the week. I think it's good to spend a few
more days in discussion about the process to perpetuate the SB, but an SB's
existance is more than justified and needs to happen. That said, and given
this discussion, I don't think anyone will create a new meta-command and
release it without putting it up to the community for input on the best way
to do it. If/when someone would ask before the SB exists, requesting 'UNOFF'
is reasonable.
If anyone has differing opinions on that, it would be great to hear them.
> > 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.
>
> I don't have a problem with the SB having an internal communications
> mechanism, but I would prefer it if I could have some reasonable assurance
> that my comments (where ever the standard place for comments ends up being)
> would get read by all (or at least a majority) of the SB.
Yes.
> Also while day to day things might take place by the SB on some quieter
> mailing list, I'm very much in favor of some regular public update of
> the status and direction of the SB.
Sure. The SB should decide how they feel it's best to update the community
as one of the first orders of business, IMO (unless there's a good concensus
reached here first).
> > 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.
>
> Something like this is always tricky.
>
> While all might aggree on the original membership, what will the
> procedures be to replace someone who leaves? to grow the committee?
> or god forbid, remove someone the commitee isn't happy with?
>
> I'm not trying to be a wet blanket. I think all of this is a great
> idea. I just think that some of these things are better off being
> decided up front, or at least everyone should be aware that they are
> still up in the air.
You bring up excellent points.
These questions imply the need for a larger body which has the power to
nominate and vote on future members of the SB. Due to the nature of this
community, membership should be voluntary and free - you're in if you say
you're in.
But, perhaps people should only be able to vote on SB members if they've
contributed via authoring parts or writing and publishing a program for
download. This would ensure people who don't know what they're talking about
can't make decisions that would effect the standards body. Also, perhaps the
4+1, or organizing committee from http://news.lugnet.com/cad/dev/?n=8484
should be able to vote.
Opinions on this? It could be argued that since membership is voluntary (and
you would have to actively state you want to be a member to be one), we will
only have knowledgeable or seriously interested parties in the voting pool.
But, it's not guaranteed. Is anyone else concerned about this?
Would it be reasonable for the SB to have the power to nominate potential
member(s) and have the voting membership vote on them? Individuals could
apply to the SB for nomination, the SB discuss it, nominate internally, the
nominees placed on a ballot for the voting members to decide upon.
I'm just throwing out ideas here.
> > 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. :-)
>
>
> I'm wondering if (and this is only an idea) some two tiered or wieghted
> voting mechanism should be considered? Maybe the committee decides on
> a resolution, and then the whole community votes yes/no? or maybe the
> committee narrows the choices down to 2, and the community picks the
> final result? Lastly maybe the committee memeber have votes that count
> 100 (or some other number) times as strong as a community members vote?
This could work, but we'd need a clear definition of 'whole community.' I'd
prefer community members who 1) have asserted membership and 2) have proven
their knowledge of the system of tools tangibly. Since the SB will be
governing the technical spec for LDraw, it's important to have informed
voters if the voters influence the SB, IMO.
> Again, I'm not promoting any of these ideas. Just throwing them out
> there in case anyone wants to pick them up and run with them.
>
> > 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.
>
>
>
> Yes smaller will help things keep moving. But it won't allow all
> parties to be represented. There needs to be some method that the
> whole community can use to add it's input, and be assured it will
> at least be heard.
That's why there would be published records of the SB's emails, and updates
from the SB for the community to discuss here. It's up to the membership to
voice disagreement here in public, and up to the SB members to honor them by
listening and engaging their opinions. I believe everyone here is acting in
good faith for the benefit of the community, and don't see how this would be
a major issue. And of course, at the end of a term for SB members, the
membership has the chance to voice their opinion with who they (re)elect.
-Tim
|
|
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
|
|
|
|
