Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Decisions [Was: Re: sorcery menu changes]

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Decisions [Was: Re: sorcery menu changes]
  • Date: Wed, 4 Jan 2006 09:14:15 -0800

On Wed, Jan 04, 2006 at 09:54:59AM +0100, Mathieu L. wrote:
> On Wed, Jan 04, 2006 at 12:00:16AM -0800, Andrew wrote:
>
> <snip>
>
> > Of course, people will always have different ideas on stuff. Is the
> > system-update feature a sorcery sub-command? or an option to the
> > sorcery tool?
> >
> > Following tradition we should now start a long verbose thread on the topic
> > without any real progress, then have it abruptly end without resolution.
> >
> > :-)
>
> I'm glad you're joking on that, bringing up what seems to be quite an
> important problem to me; because as you said it happened already several
> times and I think it really slows down smgl's evolving.
> So, what I propose here is that we think about a formal way of solving
> this kind of issue. I mean for example why don't we just call an
> official vote when there is a clear divergence of opinions between 2
> (or more) devs?
> For this precise case, since someone clearly suggested that he'd prefer
> the usual long options syntax instead of the subcommand syntax, it would
> be up to him (if you, as the responsible for such an implementation
> still don't agree with him) to call for an offcial vote.
> Then all devs
> would vote according to some rules (which sandalle would be pleased to
> come up with ;) ) and then you would have to comply with the result of
> that vote. Of course, this is only an example on how things could be
> done, but at least I think it would somehow end up in a productive
> result.
>
> What do you all think about that? (should we vote about it? ;) )
>

Thanks for your feedback. I think voting is one tool team leads have
at their disposal to decide on some issue. I'd be opposed to making it
a formal rule that whenever two developers disagree on something there
must be a vote. That would probably lead to lots of politicking, community
polarizing and would probably slow things down. I make decisions all
the time even though someone might disagree, most decisions involve
disagreeing with *someone*, unfortunatly.

There also are discussions that are useful where one party might disagree,
and it leads to something better overall, without a vote. Just being
conscious of the persons reasons for disagreement lead to compromise.

Most of the long threads tend to be based on matter of opinion though,
or on things we, as distribution maintainers, dont really know much
about. In this case, UI design. Which is why they last so long, because
no one can speak authoritatively on it.

I also think an un-informed vote is worse than none at all. So I think
its more important that when theres a divergence in opinion, someone
try to research the problem so maybe we can make a more informed decision.
In this case, research ui design principles.

Lastly, this project is pretty big, and Im attempting to split it into
bite sized pieces so we dont get hung up on stuff. Despite our best efforts,
Im sure it will at some point though :-)

With that said, I'd like to table the discussion on command line options
for now. The discussion on what items to keep, remove or add has been
useful. I'll bring it to a close soon and begin another one, probably
on menu layout.

So, those who have an interest in command line UI, please take some time
in the coming week or so to research thing a bit. Then we can approach
the discussion more informed, rather than blind leading the blind.

-Andrew

--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page