[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian needs more buildds. It has offers. They aren't being accepted.

On Mon, Feb 16, 2004 at 02:20:41AM +1000, Anthony Towns wrote:
> On Sun, Feb 15, 2004 at 02:00:36AM -0700, Jamin W. Collins wrote:
> > On Sun, Feb 15, 2004 at 03:13:53PM +1000, Anthony Towns wrote:
> > > I've asked in the past, I've been told that they don't have
> > > time. 
> > So, they did respond.  Thus, two way communcation.
> What communication, exactly, are you claiming was missing? 

In this case, status updates, plain and simple.  No NM application
should go for long (no more than three at most IMO) without an entry as
to what is happening.  

> Your email included the comment, eg, "First thing you should notice
> from this list is that there's an applicant that's been waiting on DAM
> approval with no comment for over 3 years (almost 3 1/2 years).  Yes,
> 3+ years!  That's absolutely ludicrous!"

Yes, no comment for 3 years (based on the information on the page) is
just that, ludicrous.  Even if the application is waiting on the
applicant, there should been several updates.  But this is just one of
many applicants that were waiting with no update.  There are other cases
where the process was not waiting on the applicant.

> Certainly there wasn't a comment on the webpage summary; but as tbm
> has since described there was a fair degree of communication, and the
> long pauses were mostly due to that particular applicant not
> responding to requests from the frontdesk.

In this particular case there was some communication, in others there
was not.  If the DPL didn't feel there was a problem, I don't think he
would stepped in to correct the non-problem.  The fact remains that the
DPL *did* step in to improve communication with NM applicants.  As a
result the NM process seems to be better for it.

> > > Can you see the difference between that and flaming people on
> > > -devel?
> > Sure, there was communication from both sides, not silence.
> And this is different how, exactly?

Simple communication.  If you don't get it by this point, I'm sorry.

> > > Can you possibly imagine that choosing that path might make it
> > > easier to have two-way conversations in future if something does
> > > change?
> > Sure, but both parties have to participate for two way communication
> > (by definition).  If one side is simply silent your suggestion
> > breaks down.
> Your mail also says:
> ] * Date: Sun, 13 Jul 2003 13:09:47 -0600
> ] I spent the morning working up a short script to parse
> ] http://nm.debian.org/nmlist.php and gather a list of all individuals
> ] that are listed as waiting for DAM approval.
> Did you at any point attempt to communicate this to the frontdesk
> without including comments like "That's absolutely ludicrous!", "This
> is absolutely crazy!" or just asking for more information instead of
> demanding that "something" has to be done?

No, I spoke with my sponsor concerning the delay.  I was not aware that
contacting the front desk would be of any potential help.  From all I
could gather, DAM was the absolute authority and he was utterly silent.
Thus, I began looking for who (if anyone) was in a position to effect
the DAM's authority, and made the concern public.  It's always better
(IMO) to have issues and concerns out in the open.

> > > Did you at any point ask Martin, either as front desk or as DPL,
> > > to look into this privately and in a friendly, non-accusatory
> > > manner? 
> > No.  Debian claims to be an open organization, why should this have
> > been looked into privately?  
> Because posting to lists causes a whole bunch of people who don't have
> any idea what's going on to chime in with their two cents and demand a
> long justification that doesn't benefit anyone at all.

That's your opinion.  However, it also keeps those that are interested
informed (ie. communication).  In this case a _long_ justification
wasn't needed, just increased communication (which IIRC is what I asked

> If that weren't the case, I'd agree absolutely. Unfortunately it is
> the case, and everytime someone makes the assumption that flaming
> first is a good way to go about promoting beneficial change, it
> becomes even more the case.

As others have already stated, perhaps the frequency of the complaints
indicates that there are indeed problems.

> > > Did you at any point offer any help (and follow through on that
> > > offer)?
> > Offer to help with DAM approval? No.  Didn't figure anyone would
> > accept an offer of help with DAM approval from someone awaiting it.  
> You've passed since, presumably. Have you done anything since then to
> make James' job easier?

No.  It was made very clear by others during the -devel discussion that my
assistance would not be accepted.

> > It wasn't a first resort and by no means something jumped to.  And,
> > it could have been avoided with a simple update on the NM status
> > page.  The fact remains that communication was, and still appears to
> > be, lacking where James is involved.
> Personally, one of the things I used to quite like about Debian is
> that you could join the project and be a gruff curmudgeon with no
> interpersonal skills at all, and still be respected just because you
> did good work. 

This would depend on the position held.  There are some positions within
Debian that require a certain amount of communication.  This is simple a
fact of larger projects, communication is needed.

> Aiming for technical excellence, and having people just chip in and
> solve problems when they see them rather than worrying about whose job
> it is to do what made for, IMO, a fun and effective way of writing and
> managing software. 

Without communication, this can also lead to duplication of effort.
Effort that could be spent doing other things.

> Sure, you have to treat some people differently; Espy and James were
> always terse and gruff (or at least intimidating and awe-inspiring),
> but that was okay because hey, they knew everything, and at least it
> was a good way of stopping no-nothing newbies like me from babbling
> away about things they didn't know anything about.

So, let them work on things and let someone else provide the
communication.  I believe assistants have already been suggested at
least once in this thread.

> Personally, I'd much rather work in that environment than one where
> everyone feels they should be saying something, even when they don't
> know what they're talking about, or one where people are constantly
> being put on trial and made to justify their actions. The evidence
> would suggest that that's not the way Debian works anymore, and I
> think we're incredibly poorer for that change.

Communication is a necessary part of any large project, and Debian is
certainly a large project.

> Personally, given the choice between two people, one of whom has more
> technical skills and experience, and the other of whom is more
> popular, a better manager, and a better communicator, I'd rather the
> person with the technical skills to be the one hacking on my OS.

Great, let him hack on the OS and let the individual with communication
skills communicate with others.  At this point James is in at least one
position that needs communication skills, skills that IMO he either
doesn't seem to possess or at least use.

Jamin W. Collins

This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar

Reply to: