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

Re: KDE2 - nice demolition job ...

 Aach, no sleep for the wicked this darkling eve ... at least not for me.
or morning, whatever.

On Wed, Sep 13, 2000 at 07:57:41AM -0400, Christopher C. Chimelis wrote:
> Good point :-)  I hope NM can be improved as well.  I've got someone that
> I know will help the Alpha port that's still in process after several
> months now, but it's like molasses flowing uphill in winter to get him
> finally in the project.
I hope so too!

> > 	a.  Assign more people to process applications - kind of
> > self-explanatory.
> Not to stir anything up, here, but, to the NM team, what exactly is "the
> process" for dealing with NM applications?  I've tried to stay away from
> politics mostly, but I've always been curious about this.  I know it
> involves a phone call, getting ID proof, and getting their key signed, but
> other than that, I'm clueless.  To help streamline it, is it something
> that (technically) any of us can do if we know the person or are closer
> geographically to them than the normal members of NM?
Good Question. Takers?

> > 	b.  Establish at least two teirs of contribution - people who are
> > interested in helping with less technical aspects need not be subjected to
> > the same screening process as package maintainers. So if, for example
> > somebody says "hey, could I help with paperwork or the website or
> > something ?" they can be easily accepted to work on something. Voluteering
> > should not be a full time job.  
> We get offers, but I kinda agree with the rest on this
> issue.  Documentation, IMO, is just as important as the software
> itself.  I know we don't always practice that principle, but we
> should.  To maintain docs on par with the quality of the software
> releases, I'd personally feel more comfortable knowing that anyone that's
> taking care of docs has the same knowledge/credentials/whatever that the
> package maintainers do.
 That's a good point - at least as far as actual composition goes. But there are
parts of the whole process of documenting that really don't require that much
background; eg. general editing, grammar, style, putting things into formats,
ie. general presentation. Sometimes somebody less knowledgable will have the
best feedback - they are, after all, the primary beneficiaries. And what may
be a clear description to a developer is not necessarily clear to a user.

 I happen to know an excellent technical writer that would be happy to pitch
in but he knows very little about linux so ...

> >  	c.  (optimally) Rewrite the pages that explain how to apply and 
> > give a clearer and more complete description of tasks available and what
> > level of expertise each requires.  
> I'd like to see this as well, but lack the time to volunteer to improve
> it.  I've got enough tasks just keeping Alpha going, porting HURD to
> Alpha, seeking a job (yes, I'm unemployed), keeping my wife from throwing
> my computers off of the balcony, and keeping up with my Quake clan duties
> :-P  I also think that whatever it is that NM does while processing an
> application should be documented (not per person, just in general...I
> think applicants would like to know what the steps are that you're going
> through while they wait).
> > 	d. (optimally) simplify the protocols for applying.
> Hmmm...expand on this, please...I'm not clear on what "protocols for
> applying" means.
Actually I was refering to what you just described - all of the steps involved
in applying. It is very difficult to even gather what those steps are; seems
like this could be consolidated and streamlined somewhat for at least some kinds
of participation. Preferably any, although I understand the concern for quality.
Still there is a point of diminishing returns with QA.

> Hahahaha...I ftp'ed the debs, but was wondering if there's a source
> package around.  I usually like to prod at stuff without installing it (I

Its in CVS: 
pserver:anonymous@cvs.unilinux.sourceforge.net:/cvsroot/unilinux co ddoc
 - I think that is working now, haven't actually checked recently.

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: