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

A different approach to a conflict resolution document



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
 <herp@wildsau.idv.uni-linz.ac.at>
Manoj Srivastava   <srivasta@debian.org>  <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



Reply to: