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:[EMAIL PROTECTED]:/cvsroot/unilinux co ddoc
- I think that is working now, haven't actually checked recently.
cheers,
Erik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
