On Wed, Nov 06, 2002 at 03:09:53AM +0000, Ian Jackson wrote: > Here is my current working draft. I'd like to encourage anyone who > has any substantive opinions about it, positive and negative, to let > us know. If you have something interesting to add to the discussion, > please post it. My biggest problem with the draft right now is that you have failed to consider some perfectly good comments without reason. I've attached a diff containing my proposed changes. Here is a summary of some of the changes. Many of my modifications have been grammar related. I agree with Branden's comments (although I think he may have phrased them a little harshly) regarding personal idiosyncrasies in your writing. Read the diff to see my suggestions. (I'm not going to dissect them line by line.) But here are some overall comments about grammar. 1) "..." is far more accepted that `...' and really should be used. 2) It is now widely accepted that you should only use one space between sentences. Although many sources say that either one or two is fine, most recommend only one space. The Modern Language Association's FAQ <URL:http://www.mla.org> covers this issue. 3) Using a ' - ' as a sort of "super-comma" is incorrect. The proper thing to do is to use an Em dash; but of course, this is best represented by '--'. Most sources say that there should not be any space around the em dash--like this--but putting spaces would be acceptable for use on the internet. I've left out the spaces in my diff, feel free to re-add them. 4) In English, there is no space before a question mark or exclamation mark. Don't add one! Other considerations, many of these are taken from Branden Robinson, whose e-mails you don't seem to read anymore: 1) As Branden states, "flameage" is not a word. If it were, it would be pronounced (FLAME-ee-age). Change it to "flamage" (FLAME-age), please. 2) You need to explain what you mean by the Project Leadership explicitly (I suggest you add "(i.e. the DPL or a delegate of the DPL with jurisdiction over the issue)", as Branden suggested) 3) Please include the situation where people argue over bug severities, not just re-assigning and closing/re-opening. Please read my diff. There are other suggestions I have not discussed here, as they are relatively clear, like sentence clarifications or improvements. I've attached two diffs. The first is with the -b option, and the other without. I've changed the spacing between sentences to 1 space, so that explains the difference. Thanks, -- Duncan Findlay
--- disputes.old 2002-11-05 23:25:17.000000000 -0500 +++ disputes 2002-11-05 23:23:58.000000000 -0500 @@ -6,17 +6,17 @@ Debian is a very large project. We will inevitably disagree, and occasionally get annoyed with each other. To allow us to work well -together a bit of give and take is needed, and we must be willing to +together, a bit of give and take is needed, and we must be willing to present coherent reasons for our views, and to listen to and engage with counterarguments. -This document gives some general advice about friendly interaction. -It also says what you can do when this fails: if you are having -problems working well with another Developer; or if, despite talking -to them constructively, you cannot agree. +This document gives some general advice about friendly interaction. It +also says what you can do when this fails: if you are having problems +working well with another Developer, or if, despite talking to them +constructively, you cannot agree. -2. Distinguish flameage from technical disputes and procedural errors +2. Distinguish flamage from technical disputes and procedural errors There are basically three kinds of dispute: @@ -26,7 +26,7 @@ * Procedural disagreements: these are about how the project should work, rather than about software. -* Interpersonal disputes - just `not getting along'. In any large +* Interpersonal disputes: just "not getting along". In any large community like Debian there will be personality clashes, and people you find difficult to deal with. @@ -37,10 +37,10 @@ and useful way. The best designs result when all the issues have been considered. -Useful technical discussions can become derailed by flameage. To help -avoid this, please phrase your technical disagreements moderately. -If you receive a heated complaint about some technical matter, please -try to respond to the technical, not emotional, content ! +Useful technical discussions can become derailed by flamage. To help +avoid this, please phrase your technical disagreements moderately. If +you receive a heated complaint about some technical matter, please try +to respond to the technical, not emotional, content! 3. Interpersonal behaviour @@ -54,50 +54,52 @@ Check that there is some purpose to continuing the dispute besides trying to extract an apology. If you just want an apology, and aren't getting it, then you will probably just have to put it down to -experience and move on. Some people - particularly expert -programmers! - are just a bit difficult, and it's usually best just to -put up with them. +experience and move on. Some people, particularly expert programmers, +are just a bit difficult, and it's usually best just to put up with +them. If it's a technical dispute, try to talk only about the technical -questions at issue. Avoid complaining to the other Developer that -they are being unhelpful; that'll turn the conversation into a -shouting match. +questions at issue. Avoid complaining to the other Developer that they +are being unhelpful; that'll turn the conversation into a shouting +match. -If you really can't engage helpfully - for example, because the other -Developer refuses constructive discussion - you can refer the question +If you really can't engage helpfully--for example, because the other +Developer refuses constructive discussion--you can refer the question to the Technical Committee (including, possibly, reassigning a bug -report to them) or the Project Leadership. +report to them) or the Project Leadership (i.e. the DPL or a delegate +of the DPL with jurisdiction over the issue). 4. Procedural mistakes and disagreements The Project has many rules and conventions, written and unwritten, -about when certain actions are appropriate and are inappropriate. For -example, sending a non-maintainer-upload of another Developer's -package, closing and reopening a bug report, and forwarding mail from -one place to another, are all sometimes appropriate but sometimes not. +about when certain actions are appropriate and are inappropriate, and +which fall beyond the scope of the Technical Committee. For example, +making a non-maintainer upload (NMU) of another Developer's package, +closing and reopening a bug report, and forwarding mail from one place +to another, are all sometimes appropriate but sometimes not. If you feel another Developer has erred, by failing to go about things -in the right way, you should of course tell them about it. But, -please try to make your message helpful and friendly. Probably they -didn't know about the rule in question, or understand it differently. +in the right way, you should of course tell them about it. But, please +try to make your message helpful and friendly. They probably didn't +know about the rule in question, or they understood it differently. If you can, refer the other Developer to some documentation explaining what the right process is. If such documentation does not exist, -consider writing it - it is difficult for nonexistent documentation to +consider writing it--it is difficult for nonexistent documentation to be authoritative, and a misunderstanding that arises once in the -absence of a documented procedure is likely to arise again. The -Debian Developers' Reference is usually an excellent place to document -common practice. +absence of a documented procedure is likely to arise again. The Debian +Developers' Reference is usually an excellent place to document common +practice. If the other Developer disagrees, you should seek guidance from the wider Project, so that everyone has the same ideas of how things are -supposed to work. In the end, if a firm decision needs to be made, -the Project Leadership will have to decide. +supposed to work. In the end, if a firm decision needs to be made, the +Project Leadership will have to decide. -If a Developer persistently flouts the Project's rules - written or -unwritten - then you should consult the Project Leadership for advice; -the Project Leadership will, if appropriate, warn them about their +If a Developer persistently flouts the Project's rules, written or +unwritten, then you should consult the Project Leadership for advice. +The Project Leadership will, if appropriate, warn them about their behaviour, and in extreme cases may seek the Developer's expulsion. @@ -111,10 +113,10 @@ where necessary. When you're short of time you should reduce the quantity, not the quality, of your contributions. -Be flexible; try to avoid categorical statements such as `I will never -implement that'. There is no shame in being convinced, by good +Be flexible; try to avoid categorical statements such as "I will never +implement that". There is no shame in being convinced, by good arguments, to change your mind, even if you have just been vigorously -promoting the opposite view ! +promoting the opposite view! In the case of a tradeoff between one good property and another, there are often value judgements to be made; these value judgements are @@ -124,49 +126,61 @@ If discussing the issue with all the relevant people hasn't produced a conclusion and doesn't look like it will, the Technical Committee can decide. You can refer it to the Committee in the form of a bug report -(see below); sending a summary of the situation to the Committee would +(see below). Sending a summary of the situation to the Committee would be very helpful, too. 6. Bug report etiquette Sometimes bugs are reported inappropriately; likewise, sometimes -maintainers close bug reports inappropriately. Bug reports are `todo -list' items for the whole Project; they should be closed when there is -rough consensus that the whole system is working as well as it could. +maintainers close or change the severities of bug reports +inappropriately. Bug reports are "to do list" items for the whole +Project; they should be closed when there is rough consensus that the +whole system is working as well as it could. For example, here are some examples of situations where a bug report should not be closed: -* The bug was reported against A, reassigned to B, but the maintainer -of B feels that B is working correctly (and by implication that the -bug is in A). The maintainers should talk about it to decide which -package needs to change, without closing the bug until it's fixed. +* A bug was reported against package A, reassigned to package B, but +the maintainer of B feels that B is working correctly (and by +implication that the bug is in A). The maintainers should discuss +which package needs to change, without closing the bug until it's +fixed. -* The bug was reported; the maintainer felt immediately that it was a -spurious bug report of some kind, and closed it, but the submitter +* A bug was reported; the maintainer felt immediately that it was a +spurious bug report of some kind and closed it, but the submitter disagrees with the explanation and has reopened the report for discussion. The matter should be debated until both Developers are happy. +* A bug was reported; both the maintainer and the submitter agree that +it's a defect, but disagree in their interpretations of the +definitions of bug severities. The bug should be left at the severity +determined by the package maintainer, but the report should not be +closed. The parties should discuss their disagreement within the bug +report until some mutual agreement can be reached. Note that the +Release Manager may regard a bug as "release-critical" (or not) +irrespective of its severity in the BTS. + While a situation is being discussed, any relevant bug report(s) should remain open. If a package maintainer closes your bug report, you may reopen it if you wish to continue the discussion. -At no other time should you play `bug report tag' with anyone else. -If someone makes a change to a bug report status which you disagree -with you should *discuss* the matter with them but *not* immediately -undo their action in the BTS, except to reopen the bug to stop it -getting lost. If you are unable to reach a conclusion through -constructive discussion, you should ask for outside help with -resolving your dispute, as outlined above. +Under no other circumstances should you get into a back-and-forth with +a package maintainer, changing the state of the bug in the BTS. If +someone makes a change to a bug report status which you disagree with +you should *discuss* the matter with them and *not* immediately undo +their action in the BTS, except to reopen the bug to stop it getting +lost. If you are unable to reach a conclusion through constructive +discussion, you should ask for outside help with resolving your +dispute, as outlined above. Note that while the Technical Committee is also happy to help resolve disputes over individual bug reports, you should not refer a matter to the Committee until you have tried to explore the issue yourselves. When this has been done, the bug report logs should contain detailed description of the problem and records of your discussions, and you -may then reassign the bug report to the pseudo-package `tech-ctte'. +may then reassign the bug report to the pseudo-package "tech-ctte". For more information about the committee, see -http://www.debian.org/devel/tech-ctte. +<URL:http://www.debian.org/devel/tech-ctte>.
--- disputes.old 2002-11-05 23:25:17.000000000 -0500 +++ disputes 2002-11-05 23:23:58.000000000 -0500 @@ -1,22 +1,22 @@ DISPUTES BETWEEN DEVELOPERS -A *DRAFT* recommendation by the Technical Committee. +A *DRAFT* recommendation by the Technical Committee. 1. Motivation -Debian is a very large project. We will inevitably disagree, and -occasionally get annoyed with each other. To allow us to work well -together a bit of give and take is needed, and we must be willing to +Debian is a very large project. We will inevitably disagree, and +occasionally get annoyed with each other. To allow us to work well +together, a bit of give and take is needed, and we must be willing to present coherent reasons for our views, and to listen to and engage with counterarguments. -This document gives some general advice about friendly interaction. -It also says what you can do when this fails: if you are having -problems working well with another Developer; or if, despite talking -to them constructively, you cannot agree. +This document gives some general advice about friendly interaction. It +also says what you can do when this fails: if you are having problems +working well with another Developer, or if, despite talking to them +constructively, you cannot agree. -2. Distinguish flameage from technical disputes and procedural errors +2. Distinguish flamage from technical disputes and procedural errors There are basically three kinds of dispute: @@ -26,7 +26,7 @@ * Procedural disagreements: these are about how the project should work, rather than about software. -* Interpersonal disputes - just `not getting along'. In any large +* Interpersonal disputes: just "not getting along". In any large community like Debian there will be personality clashes, and people you find difficult to deal with. @@ -34,70 +34,72 @@ For Debian to be able to construct good software, we must be able to disagree with the way something is done or proposed in a constructive -and useful way. The best designs result when all the issues have been +and useful way. The best designs result when all the issues have been considered. -Useful technical discussions can become derailed by flameage. To help -avoid this, please phrase your technical disagreements moderately. -If you receive a heated complaint about some technical matter, please -try to respond to the technical, not emotional, content ! +Useful technical discussions can become derailed by flamage. To help +avoid this, please phrase your technical disagreements moderately. If +you receive a heated complaint about some technical matter, please try +to respond to the technical, not emotional, content! 3. Interpersonal behaviour If you are having problems getting along with another developer, firstly consider whether there's anything you can do to try to improve -the situation. Send only moderate, reasonable messages; offer to talk +the situation. Send only moderate, reasonable messages; offer to talk in some other way, perhaps even by phone (it's much easier to give offence accidentally by email or on IRC than on the phone). Check that there is some purpose to continuing the dispute besides -trying to extract an apology. If you just want an apology, and aren't +trying to extract an apology. If you just want an apology, and aren't getting it, then you will probably just have to put it down to -experience and move on. Some people - particularly expert -programmers! - are just a bit difficult, and it's usually best just to -put up with them. +experience and move on. Some people, particularly expert programmers, +are just a bit difficult, and it's usually best just to put up with +them. If it's a technical dispute, try to talk only about the technical -questions at issue. Avoid complaining to the other Developer that -they are being unhelpful; that'll turn the conversation into a -shouting match. +questions at issue. Avoid complaining to the other Developer that they +are being unhelpful; that'll turn the conversation into a shouting +match. -If you really can't engage helpfully - for example, because the other -Developer refuses constructive discussion - you can refer the question +If you really can't engage helpfully--for example, because the other +Developer refuses constructive discussion--you can refer the question to the Technical Committee (including, possibly, reassigning a bug -report to them) or the Project Leadership. +report to them) or the Project Leadership (i.e. the DPL or a delegate +of the DPL with jurisdiction over the issue). 4. Procedural mistakes and disagreements The Project has many rules and conventions, written and unwritten, -about when certain actions are appropriate and are inappropriate. For -example, sending a non-maintainer-upload of another Developer's -package, closing and reopening a bug report, and forwarding mail from -one place to another, are all sometimes appropriate but sometimes not. +about when certain actions are appropriate and are inappropriate, and +which fall beyond the scope of the Technical Committee. For example, +making a non-maintainer upload (NMU) of another Developer's package, +closing and reopening a bug report, and forwarding mail from one place +to another, are all sometimes appropriate but sometimes not. If you feel another Developer has erred, by failing to go about things -in the right way, you should of course tell them about it. But, -please try to make your message helpful and friendly. Probably they -didn't know about the rule in question, or understand it differently. +in the right way, you should of course tell them about it. But, please +try to make your message helpful and friendly. They probably didn't +know about the rule in question, or they understood it differently. If you can, refer the other Developer to some documentation explaining -what the right process is. If such documentation does not exist, -consider writing it - it is difficult for nonexistent documentation to +what the right process is. If such documentation does not exist, +consider writing it--it is difficult for nonexistent documentation to be authoritative, and a misunderstanding that arises once in the -absence of a documented procedure is likely to arise again. The -Debian Developers' Reference is usually an excellent place to document -common practice. +absence of a documented procedure is likely to arise again. The Debian +Developers' Reference is usually an excellent place to document common +practice. If the other Developer disagrees, you should seek guidance from the wider Project, so that everyone has the same ideas of how things are -supposed to work. In the end, if a firm decision needs to be made, -the Project Leadership will have to decide. +supposed to work. In the end, if a firm decision needs to be made, the +Project Leadership will have to decide. -If a Developer persistently flouts the Project's rules - written or -unwritten - then you should consult the Project Leadership for advice; -the Project Leadership will, if appropriate, warn them about their +If a Developer persistently flouts the Project's rules, written or +unwritten, then you should consult the Project Leadership for advice. +The Project Leadership will, if appropriate, warn them about their behaviour, and in extreme cases may seek the Developer's expulsion. @@ -106,15 +108,15 @@ Most disagreements in the Project are technical; this is good. The vast majority are useful, and can be resolved by constructive -discussion where all aspects of the problem are considered. All +discussion where all aspects of the problem are considered. All Developers should participate constructively in technical discussions -where necessary. When you're short of time you should reduce the +where necessary. When you're short of time you should reduce the quantity, not the quality, of your contributions. -Be flexible; try to avoid categorical statements such as `I will never -implement that'. There is no shame in being convinced, by good +Be flexible; try to avoid categorical statements such as "I will never +implement that". There is no shame in being convinced, by good arguments, to change your mind, even if you have just been vigorously -promoting the opposite view ! +promoting the opposite view! In the case of a tradeoff between one good property and another, there are often value judgements to be made; these value judgements are @@ -123,50 +125,62 @@ If discussing the issue with all the relevant people hasn't produced a conclusion and doesn't look like it will, the Technical Committee can -decide. You can refer it to the Committee in the form of a bug report -(see below); sending a summary of the situation to the Committee would +decide. You can refer it to the Committee in the form of a bug report +(see below). Sending a summary of the situation to the Committee would be very helpful, too. 6. Bug report etiquette Sometimes bugs are reported inappropriately; likewise, sometimes -maintainers close bug reports inappropriately. Bug reports are `todo -list' items for the whole Project; they should be closed when there is -rough consensus that the whole system is working as well as it could. +maintainers close or change the severities of bug reports +inappropriately. Bug reports are "to do list" items for the whole +Project; they should be closed when there is rough consensus that the +whole system is working as well as it could. For example, here are some examples of situations where a bug report should not be closed: -* The bug was reported against A, reassigned to B, but the maintainer -of B feels that B is working correctly (and by implication that the -bug is in A). The maintainers should talk about it to decide which -package needs to change, without closing the bug until it's fixed. +* A bug was reported against package A, reassigned to package B, but +the maintainer of B feels that B is working correctly (and by +implication that the bug is in A). The maintainers should discuss +which package needs to change, without closing the bug until it's +fixed. -* The bug was reported; the maintainer felt immediately that it was a -spurious bug report of some kind, and closed it, but the submitter +* A bug was reported; the maintainer felt immediately that it was a +spurious bug report of some kind and closed it, but the submitter disagrees with the explanation and has reopened the report for -discussion. The matter should be debated until both Developers are +discussion. The matter should be debated until both Developers are happy. +* A bug was reported; both the maintainer and the submitter agree that +it's a defect, but disagree in their interpretations of the +definitions of bug severities. The bug should be left at the severity +determined by the package maintainer, but the report should not be +closed. The parties should discuss their disagreement within the bug +report until some mutual agreement can be reached. Note that the +Release Manager may regard a bug as "release-critical" (or not) +irrespective of its severity in the BTS. + While a situation is being discussed, any relevant bug report(s) -should remain open. If a package maintainer closes your bug report, +should remain open. If a package maintainer closes your bug report, you may reopen it if you wish to continue the discussion. -At no other time should you play `bug report tag' with anyone else. -If someone makes a change to a bug report status which you disagree -with you should *discuss* the matter with them but *not* immediately -undo their action in the BTS, except to reopen the bug to stop it -getting lost. If you are unable to reach a conclusion through -constructive discussion, you should ask for outside help with -resolving your dispute, as outlined above. +Under no other circumstances should you get into a back-and-forth with +a package maintainer, changing the state of the bug in the BTS. If +someone makes a change to a bug report status which you disagree with +you should *discuss* the matter with them and *not* immediately undo +their action in the BTS, except to reopen the bug to stop it getting +lost. If you are unable to reach a conclusion through constructive +discussion, you should ask for outside help with resolving your +dispute, as outlined above. Note that while the Technical Committee is also happy to help resolve disputes over individual bug reports, you should not refer a matter to the Committee until you have tried to explore the issue yourselves. When this has been done, the bug report logs should contain detailed description of the problem and records of your discussions, and you -may then reassign the bug report to the pseudo-package `tech-ctte'. +may then reassign the bug report to the pseudo-package "tech-ctte". For more information about the committee, see -http://www.debian.org/devel/tech-ctte. +<URL:http://www.debian.org/devel/tech-ctte>.
Attachment:
pgp0Nyp6UhBWr.pgp
Description: PGP signature