Re: Questions for DPL candidates: casting the lead to fathom our course
Hi Steve,
I'd like to avoid discussing this on -vote, the questions were
primarily to elicit your opinions, and we aren't voting on mine ;-)
If there are topics you think should be discussed further, please
feel free to move them to the appropriate forum for the issue.
Since you've turned a couple of the questions back at me though,
I'll try to elaborate a little more on what I was hoping to troll
from _your_ vision of where we are going and how we might get there.
A leader with majority support is not much use to us, but a leader
with a vision we can all see is priceless. I want to know what you
can see, far more than I care about whether you yourself have the
right answer to a particular question.
Seeing the real problem is always far harder than brainstorming for
solutions to it. So personally, I'd always prefer a seer for a
leader than someone with a +12 invincible sword who can make every
answer have the simple solution of "My way". Hence I want to know
who of you sees what before I spend My hard earned vote...
If there are things you think the voters should know, feel free to
send that to -vote, but questions to me, lets take somewhere else.
We can always air them later if a good answer fits in a paragraph ;-)
On Thu, Mar 15, 2007 at 11:50:40PM +0000, Steve McIntyre wrote:
> On Sat, Mar 10, 2007 at 07:23:06PM +1030, Ron wrote:
> >Now that we have collaborative tools such as Alioth, which
> >allow any developer to allow anyone they deem fit to have
> >direct commit access to their work -- and leaves the ultimate
> >responsibility for what happens there to that developer or
> >team of developers who make signed uploads to the disto,
> >do we still have the same pressures on filling the keyring
> >with as many people as we can, as fast as we can -- or should
> >inclusion in it be perhaps even more limited to people who
> >have proven their judgement for what belongs in the archive
> >at any point in a release cycle and what does not?
>
> I'm curious as to how you'd propose to evaluate the judgement of those
> people.
That's not the part that is rocket science, and in fact we already
have the mechanisms in place that do this. Ignoring for the moment
translators and the like [1] because only people uploading packages
presently _need_ to be in the keyring, then the question of judgement
really falls to the sponsors of NM packages. I'm personally beginning
to think that good release management skills is an attribute we should
cultivate -- but the question is: what attributes do _you_ think we
need to focus on to grow effectively?
[1] - which I'd love to be able to have update their bits of my packages
without me getting in their way, btw.
At a simple division there are two types of people coming through NM,
people who already have all the skills they need to effectively
distribute what they maintain, and people who want to learn them.
There are other groups, but these cover most who'll actually make it
through.
So our sponsors and mentors, and all the other -ors we have, have
effectively created their own apprenticeship scheme. We now have
the tools for any developer, to let any other developer come and
do useful things under their domain of responsibility. Or come
and learn them if they seem to have an aptitude for the subject.
If you recognise that, then what things are most valuable to the
distro for these people to learn well? Everyone brings their own
unique personal knowledge to the party, but what do we _all_ need
to be good, or better, at for the distro to grow the way you'd like
it to? For releases to go out somewhere near schedule? For each
to be a slicker user experience than the last?
> Team-based maintenance via alioth (or elsewhere) is a growing
> commodity, and that's undoubtedly a good thing.
I'm not convinced that teams are a good way to assess _individual_
judgement. There are plenty of people in the world who will only
remain alive for the coming weeks because there are teams of people
able to provide them with food and shelter and warmth. Take away
the team and they would be in dire straights indeed.
That's not to say teams are a bad thing. They let us do things we
could not do alone, and people can be part of them from the first
day they do something useful, without having to endure an ancillary
process...
But if you are the new chum learning they only tell us you can work
in a team, when what it appears we need to know, is can you produce
releasable software that meets our standards and keep it that way.
If you disagree with that, consider it a question ;-)
To release the Worlds Best OS, first it has to release. And that's
not going to get easier as we grow -- and as more and more large
subsystems emerge which each have their own dependency trees.
It's already hard, if its not going to get so much harder as to be
completely intractable, how are we going to get better at it?
> For the more important packages that are likely to hold up a release,
> team maintenance is a great help.
Do you have some numbers on that? ;-) I'd be curious to see a
comparison between the states of various team maintained packages,
with the time when they had a single, dedicated, and probably in
their own way insane, maintainer...
I do agree those people are hard to replace with another single
individual when they finally burn out though...
That's something else large organisations tend to do badly at.
If you have ideas on how we can escape than phenomenon, I'd
love to hear them too ...
> I don't think it would be a valid or fair thing to do to keep people
> at that level rather than allowing them to take on their own packages
> as full DDs as well.
I don't think we _can_ properly assess the trust we have in them
until we've given them some. Again if we are just talking about
the keyring though, then assessing their sponsored packages is
perfectly sufficient if we have good criteria to assess them by.
If a package you are responsible for is not suitable to be in
the dist, then you don't need a key in the keyring to be able
to upload it. This bit at least all seems pretty self-evident.
We've seen some questions recently on sponsors and sponsored
packages. Not necessarily in the most tactful tone, but the
process itself I think is a healthy one.
Do you think we could do better at this[2]? If so, how?
[2] - the assessment that is, we'll give the tact a bit more time
to sink in... That seems to be slowly catching on. ;)
> >Do you think we should be continually raising the bar of
> >skill required as the project as a whole refines its best
> >practices, or should we be lowering it to match the average
> >level of people now interested in contributing as our mass
> >market appeal grows?
>
> We should always be keeping or (better) raising our standards,
> striving for "continuous improvement"[1]. But equally we should also
> be better recognising a lot more of the people who help make Debian
> what it is - the translators, documentation authors, admins,
> etc. etc. All these people bring their skills and efforts to the
> party, yet at the moment only those people that upload packages get
> much recognition (be that the magical debian.org address, access to
> -private, voting rights, whatever). How can we fix that? I'd much
> rather we have that *wider* discussion than simply think about the
> standards of package maintainers.
Indeed, I've already traded some views off list with the other
candidates who've responded, on precisely these 'forgotten' people.
We all seem to be in agreement that more can be done (not to at all
discount that much is _being_ done) to improve the interfaces for
people performing specialised tasks.
I don't really have the time to implement the things I'd like to
see improve here, but if anyone wants to know, I'll be more than
happy to tell them a few things that would make things better for
myself and the people in this category who depend on me for
uploading their work...
The DPL candidates seem to be gradually evolving their own scheme
for dividing up the work that each professes an interest in amongst
themselves whoever wins, so I have no problem with leaving it to
you all to decide who will do what about it when ;-) I do think
it would be a good project for one of more of you to take on though.
Whether whoever wins is behind it or not ... ;-)
> >Lastly, and in the context of all this, how do you see that
> >the role of DPL must change to keep it relevant to an
> >increasing body of volunteers that cannot in fact be led by
> >simple proclamation from the top. We've seen numerous times
> >now that a DPL (or GR) which insists on something that is not
> >backed up by consensus only leads to increased divisiveness
> >in the project and less real work being done by those who's
> >opinion has been ignored or defiled. How can we keep this
> >role as one which guides us all through the clear water at
> >the crucial points of navigation and avoid the politics of
> >casting some people up on the rocks just to find out where
> >they are? Especially when the role is mostly symbolic and
> >its holder is only able to make small course changes before
> >people start falling overboard en-mass or plotting a course
> >of mutiny...
>
> Unfortunately, as Debian has grown we do seem to have reached a point
> where some arguments become self-feeding. There will always be
> disagreements amongst developers - we all tend to have strong
> opinions. Where possible, consensus is wonderful. In cases where it's
> not possible, people who have "lost" the argument eventually have to
> live with that and move on. Pet ideas are all well and good, but (I
> hope!) we're all here to make the best possible free operating system
> and sometimes that means making compromises from our own original
> positions.
I suspect the truth in that hinges on how many people share any
particular 'pet' idea. Any contentious idea that goes to a vote
which can make Q for its opposition, is far from being resolved,
and probably not too far from being voted on again before the next
release is even done.
For things like what our logo is, and who our leader@ is, its not
really all that important so long as neither is particularly
offensive to the people they affect. But for technical issues,
voting doesn't have quite as good a track record of making the
best selection. You could say we've 'lost' the RPM argument.
But I don't think you'll get a lot of support from us for dropping
.deb just yet.
Perhaps sometimes we need to not rush things to a vote to declare
a winner, (or more normally, some losers) but rather all agree that
we don't have consensus and the subject needs to be looked at in more
detail to see what we do and do not agree on about it. It takes much
patience and dedication to be the best at anything. Having only enough
patience to convince half of the people, half of the time, doesn't quite
seem like the breakfast of champions. And voting that someone else
should do something seems somewhat removed from proof by here's the code
to do it.
I have no doubt whatsoever that all of us are here to build the Best OS.
Very few people volunteer to join a group of losers. The real question
is, how many of us actually know how, how many of us are just being
taken along in the current, and how do we improve that particular S/N
ratio over time in our future?
Will smaller working groups like a DPL committee, or the various
other ad-hoc teams that have formed around negotiating tricky
problems, help build the seeds that the rest of us can crystallise
consensus around, more quickly than our traditional all-in method?
Have they already? There are probably a few examples we can take
some good points from ...
FWIW
It seems a bit like an oxymoron to me to put 'best' and 'compromise'
in the same sentence. Compromise is 'etch-ignore'. Best is not
losing anymore. Both have their advantages, and their time and place,
but each seems to be an acknowledgement that you've forsaken the other.
However temporarily.
We mostly seem to be pretty smart people, for some definitions of
smart -- so any time a group of them can form in opposition to some
idea, I always have to stop and ask myself, what do they know that
I don't. The answers can be surprising and enlightening if I'm
prepared to give the question some thought, and the group really is
in the minority.
I'd hate to see that lost to the normalisation of majority rule.
That's a bit like compromising on whether I put my parachute on
before I get out of the plane. There are consequences that cannot
be reversed.
Anyway, we're off into my opinion, and that's my weakness showing
again... this is Big and neither of us will solve it in a few lines
here. If you're really interested in following that one up, let's
take it somewhere more appropriate.
> Using that as a background, I belive the DPL's job within the project
> should therefore be to help establish the compromises where they are
> needed, and to encourage people to have fruitful discussions that
> actually lead somewhere.
What exactly can the DPL do there that they could not do as a similarly
talented person without that hat on? Aside from attempting to play
games with delegate appointments, the constitution would seem to protect
the rest of the developers from having to make any compromise that they
did not personally see fit. So if the DPL role gives neither more power
or more time in the day to resolve these issues, how can they contribute
more than they otherwise would have to any such resolution process?
I think everyone should be doing what you suggest here, and probably
that for every problem, we have a person somewhere who would be the
best placed to fairly arbitrate discussion on it, so what am I missing
that puts a trump card up the DPL's sleeve here?
Cheers,
Ron
Reply to: