Hi,
[Please follow up to debian-project]
Well, given that I have deep philosophical differences with
the document Ian is crafting, and acknowledging that one ought to
have an alternative, I have decided to start an collaborative effort
to create a new one.
Unlike Ian, this is not MY draft -- this is an open invitation
to anyone who wishes to contribute, to help us craft something that
works. I do not claim to know the one true way, nor do I claim that I
alone can come up with scenarios, solutions, and language that the
developers from such diverse backgrounds can identify with and feel
comfortable about.
We do need a focal point for this effort, a person who shall
gather the contributions, and meld them into a document, and I am
volunteering to be that person. (I would also love to have other
people volunteer to share this responsibility).
The way I want to structure this document is to start with a
needs analysis -- kinda like a social use case analysis.
How do we envisage this document being used? When shall people
refer to it? What kinds of conflicts can be thus resolved?
Once we have done that, we can start with bullet points for
possible solutions for the scenarios we have come up with. I would
prefer the solutions to be slightly more concrete than ``now,
children, just play nice'' -- decision trees, with options that y'all
think may help in various stages of the sometimes vicious dog fights
that seem to develop on our mailing lists.
I firmly believe we can mention guidelines of nettiquette
without being patronizing. We can extend common conventions like the
USENET Godwin's Law convention for our use ;-)
To seed the discussion, I am starting with a few use cases
(stolen shamelessly from Ian's draft):
a) Disagreement about Bug Report Severities
i) What to do if you are the reporter
ii) What to do if you are the developer
b) Technical policies and other problems for which there is no clear
cut technical solution
c) Non technical issue (like crafting a document like this)
d) Disagreements in specialized sub-projects
e) Disagreement about tailoring a package, default configurations,
and choices.
I would appreciate any comments, including, but not limited
to, more use cases, opinions on whether we need to go into more
details, and whether I am being a moron (hi aj).
manoj
--
Sorry for mailing this article, I've obviously made a typo (168!=186)
that's the price for being up all night and doing some "quick" checks
before you go to bed .... Herbert Rosmanith
<[EMAIL PROTECTED]>
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
