Unbearable related to misspellings ideas (was Re: draft-moonesamy-ietf-conduct-3184bis)
On 9/1/13, Eduardo A. Suárez esua...@fcaglp.fcaglp.unlp.edu.ar wrote: What is unbearable to me is that in more than one discussion in a mailing list someone's opinion is censored because misspell their ideas or opinions. I don't think that is unbearable, usually in communications between IP devices/machines it happens that words or digits are missed or changed but because the receiver is able to detect the error and find out the mistake by the context of the message, so it corrects the words/digits. Therefore, I recommend all (poster and reader, native and non-native English speakers) to try to detect errors and correct them to make ideas or opinion clear at receiver. We always get misspellings in I-Ds, and even RFCs (some even not made errata because understood/detected-and-corrected), therefore, we are use to it, so we can do same in our discussions. AB
Re: draft-moonesamy-ietf-conduct-3184bis
At 23:15 31-08-2013, Scott Kitterman wrote: That does seem better, but don't all parties have an obligation to attempt to communicate clearly? The new text is as follows: Participants, particularly those with English as a first language, attempt to accommodate the needs of other participants by communicating clearly. Participants try to accommodate each other. At 09:08 01-09-2013, Barry Leiba wrote: I think Scott has put this perfectly, and it's exactly right. The main point is clear communication. Everything else is advice about how to achieve that. Yes. We're all individuals, and we have different tolerance levels -- some of us are more patient than others in trying to understand. That said, this is also a collaborative environment, where everyone needs to do her part. Native speakers need to use a level of English that's likely to be accessible to non-natives, and to do the best they can to understand what others are saying. Non-native speakers need to do what they can to improve their English skills. Everyone has responsibility. Yes. At 09:22 01-09-2013, Dave Crocker wrote: If the document only cites concepts or principles or other terms of abstraction, each of us is likely to interpret them /very/ differently. Especially for a topic like this. Worse, even if we interpret them in the same way, we might not understand what behaviors to attempt or to avoid, since that often requires some understanding of the differences between cultures and people. Yes. Brian Trammell explained it better than I could (see http://www.ietf.org/mail-archive/web/diversity/current/msg00289.html ). Melinda Shore commented about what to avoid (e.g. highly idiomatic language). Somebody in the group, WG Chair, Area Director, or even a participant, might explain what is causing a communication problem. At the other end someone who has a problem understanding what is being said can contact the WG Chair or Area Director privately so that they can step in and help. Regards, S. Moonesamy
Re: draft-moonesamy-ietf-conduct-3184bis
On Sep 3, 2013 5:47 AM, S Moonesamy sm+i...@elandsys.com wrote: At the other end someone who has a problem understanding what is being said can contact the WG Chair or Area Director privately so that they can step in and help. Because there are communication problems every few minutes, this seems like a large burden to place on those who should be able to focus on keeping the work as a whole running smoothly. Someone who has a problem understanding can speak to individuals privately. If they are rebuffed and want intervention, then they could go to a WG chair... or perhaps to someone who is part of a set of volunteers for helping in communication (we need a new badge sticker). In any case, please don't assign more small responsibilities to the people who we depend on for pushing our work forward.
Re: draft-moonesamy-ietf-conduct-3184bis
S Moonesamy sm+i...@elandsys.com wrote: At 23:15 31-08-2013, Scott Kitterman wrote: That does seem better, but don't all parties have an obligation to attempt to communicate clearly? The new text is as follows: Participants, particularly those with English as a first language, attempt to accommodate the needs of other participants by communicating clearly. Participants try to accommodate each other. Except for the part between the commas it's great. As written, it presumes that a mis-communication between a native speaker of English and someone who isn't is the fault of the native speaker. I don't think this is appropriate. Scott K At 09:08 01-09-2013, Barry Leiba wrote: I think Scott has put this perfectly, and it's exactly right. The main point is clear communication. Everything else is advice about how to achieve that. Yes. We're all individuals, and we have different tolerance levels -- some of us are more patient than others in trying to understand. That said, this is also a collaborative environment, where everyone needs to do her part. Native speakers need to use a level of English that's likely to be accessible to non-natives, and to do the best they can to understand what others are saying. Non-native speakers need to do what they can to improve their English skills. Everyone has responsibility. Yes. At 09:22 01-09-2013, Dave Crocker wrote: If the document only cites concepts or principles or other terms of abstraction, each of us is likely to interpret them /very/ differently. Especially for a topic like this. Worse, even if we interpret them in the same way, we might not understand what behaviors to attempt or to avoid, since that often requires some understanding of the differences between cultures and people. Yes. Brian Trammell explained it better than I could (see http://www.ietf.org/mail-archive/web/diversity/current/msg00289.html ). Melinda Shore commented about what to avoid (e.g. highly idiomatic language). Somebody in the group, WG Chair, Area Director, or even a participant, might explain what is causing a communication problem. At the other end someone who has a problem understanding what is being said can contact the WG Chair or Area Director privately so that they can step in and help. Regards, S. Moonesamy
Re: draft-moonesamy-ietf-conduct-3184bis
Spencer Dawkins spencerdawkins.i...@gmail.com wrote: On 9/3/2013 9:26 AM, Scott Kitterman wrote: S Moonesamy sm+i...@elandsys.com wrote: The new text is as follows: Participants, particularly those with English as a first language, attempt to accommodate the needs of other participants by communicating clearly. Participants try to accommodate each other. Except for the part between the commas it's great. As written, it presumes that a mis-communication between a native speaker of English and someone who isn't is the fault of the native speaker. I don't think this is appropriate. Hi, Scott, Keeping in mind that we wouldn't be looking at this text in the first place, if it was easy to communicate ... ;-) What I thought the parenthetical presumed, was that a native English speaker(*) might have more tools to use in helping repair mis-communication - for example, a native English speaker might have a larger vocabulary, if paraphrasing would help understanding, and might be more likely to use obscure English idioms(**) that don't translate easily into other languages and cultures. So, not that mis-communication is the native English speaker's fault, but that the native English speaker might be better positioned to make the first move to improve communication. Spencer (*) Obviously there are people, including people at the IETF, who learned English as a second (or third, or ...) language and now have better English communication skills than I do, so native English speaker/English as a first language might benefit from rephrasing, if the thought survives. (**) My Chinese co-workers can conjure up 5000 years of rich idioms, and I enjoy hearing them, but they don't seem to translate them into English and insert them into conversations nearly as often as I insert idioms into conversations ... I think that is a given without having pre-emptive blame assignment in the text. Scott K
Re: draft-moonesamy-ietf-conduct-3184bis
On 9/3/2013 9:26 AM, Scott Kitterman wrote: S Moonesamy sm+i...@elandsys.com wrote: The new text is as follows: Participants, particularly those with English as a first language, attempt to accommodate the needs of other participants by communicating clearly. Participants try to accommodate each other. Except for the part between the commas it's great. As written, it presumes that a mis-communication between a native speaker of English and someone who isn't is the fault of the native speaker. I don't think this is appropriate. Hi, Scott, Keeping in mind that we wouldn't be looking at this text in the first place, if it was easy to communicate ... ;-) What I thought the parenthetical presumed, was that a native English speaker(*) might have more tools to use in helping repair mis-communication - for example, a native English speaker might have a larger vocabulary, if paraphrasing would help understanding, and might be more likely to use obscure English idioms(**) that don't translate easily into other languages and cultures. So, not that mis-communication is the native English speaker's fault, but that the native English speaker might be better positioned to make the first move to improve communication. Spencer (*) Obviously there are people, including people at the IETF, who learned English as a second (or third, or ...) language and now have better English communication skills than I do, so native English speaker/English as a first language might benefit from rephrasing, if the thought survives. (**) My Chinese co-workers can conjure up 5000 years of rich idioms, and I enjoy hearing them, but they don't seem to translate them into English and insert them into conversations nearly as often as I insert idioms into conversations ...
Re: draft-moonesamy-ietf-conduct-3184bis
Hi, Quoting Abdussalam Baryun abdussalambar...@gmail.com: I always think the problem of not understanding a message in IETF is not the fault of the transmitter, but it is the receiver's fault. The receiver SHOULD make more efforts to understand, or send a reply to request clarifications (specially in IETF WGs when discussing technical issues). The fault cannot be the used-language or the way the language is used, but the fault can be low performance of communication or low purpose of such work at receiver end. the problem is that when one is arguing against the opinion of another person, it is very easy for the recipient to respond you do not write well and I do not understand and so disqualify his opponent. I think that isn't being applied the concepts of Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astronómicas y Geofísicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 This message was sent using IMP, the Internet Messaging Program.
Re: draft-moonesamy-ietf-conduct-3184bis
Hi, Quoting S Moonesamy sm+i...@elandsys.com: The original phrasing is as follows: English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English speakers attempt to speak clearly and a bit slowly and to limit the use of slang in order to accommodate the needs of all listeners. The draft reuses the text. That text could be rewritten as: English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English participants attempt to accommodate the needs of other participants by communicating clearly. I think both parties have to try to express clearly. Those who do not have the English as their native language should also try to do so. What is unbearable to me is that in more than one discussion in a mailing list someone's opinion is censored because misspell their ideas or opinions. Regards, Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astronómicas y Geofísicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 This message was sent using IMP, the Internet Messaging Program.
Re: draft-moonesamy-ietf-conduct-3184bis
That does seem better, but don't all parties have an obligation to attempt to communicate clearly? The new text is as follows: Participants, particularly those with English as a first language, attempt to accommodate the needs of other participants by communicating clearly. Participants try to accommodate each other. I agree with Scott that the stuff between the commas doesn't belong here. That is, it doesn't belong *here*; it can certainly go into a sentence or paragraph with advice for native English speakers. Consider something like this instead: Participants must do their best to accommodate the needs of other participants by communicating clearly. When faced with English that is difficult to understand, we must all make the effort to understand it nonetheless, engaging in conversation to clarify what was meant. Native English speakers, in particular, should be careful with the use of slang and cultural references that might not be well known to everyone. That might not be exactly right; please try to understand me, and tweak as necessary. :-) Barry
Re: draft-moonesamy-ietf-conduct-3184bis
Barry Leiba barryle...@computer.org wrote: That does seem better, but don't all parties have an obligation to attempt to communicate clearly? The new text is as follows: Participants, particularly those with English as a first language, attempt to accommodate the needs of other participants by communicating clearly. Participants try to accommodate each other. I agree with Scott that the stuff between the commas doesn't belong here. That is, it doesn't belong *here*; it can certainly go into a sentence or paragraph with advice for native English speakers. Consider something like this instead: Participants must do their best to accommodate the needs of other participants by communicating clearly. When faced with English that is difficult to understand, we must all make the effort to understand it nonetheless, engaging in conversation to clarify what was meant. Native English speakers, in particular, should be careful with the use of slang and cultural references that might not be well known to everyone. That might not be exactly right; please try to understand me, and tweak as necessary. I do think that's better. In my experience, once code of conduct type language is codified, eventually someone will try to use it as a hammer. It needs to be crafted with this assumption in mind. Thanks, Scott K
Re: draft-moonesamy-ietf-conduct-3184bis
On 9/3/13 6:50 AM, Scott Kitterman wrote: I think that is a given without having pre-emptive blame assignment in the text. *Blame*? I know that I've inadvertently used regional idioms that were hard for non-native speakers to understand and I've been grateful when it's been pointed out. Trying to figure out where things get confusing and correcting that is a net positive for the organization. Characterizing that process as blame is not. We're supposed to be engineers. Let's fix stuff. Melinda
Re: draft-moonesamy-ietf-conduct-3184bis
On Tuesday, September 03, 2013 17:07:02 Melinda Shore wrote: On 9/3/13 6:50 AM, Scott Kitterman wrote: I think that is a given without having pre-emptive blame assignment in the text. *Blame*? I know that I've inadvertently used regional idioms that were hard for non-native speakers to understand and I've been grateful when it's been pointed out. Trying to figure out where things get confusing and correcting that is a net positive for the organization. Characterizing that process as blame is not. We're supposed to be engineers. Let's fix stuff. I agree, but we're people too. It's been my experience that if a code of conduct assigns primary responsibility for something to one party (in this case the native English speaker), it will later get used as a hammer whether it was intended as such or not. I agree that trying to figure things out is a net positive. What I want to avoid is someone making excuses claiming that since they aren't a native speaker it's somebody else's problem to understand them. The responsibility to attempt to communicate clearly is equal. Someone more fluent in English may have more tools at their disposal and may be able to contribute to the resolution of the problem more extensively, but that doesn't given them any more or less inherent burden. Scott K
Re: draft-moonesamy-ietf-conduct-3184bis
On 9/3/13 6:58 PM, Scott Kitterman wrote: I agree that trying to figure things out is a net positive. What I want to avoid is someone making excuses claiming that since they aren't a native speaker it's somebody else's problem to understand them. I'd like to think that we're going to retain at least some small vestige of common sense in the future (although it's looking questionable). I suppose one could argue the reverse, that by failing to include this as a guideline we may be empowering native English speakers to complain that non-native English speakers are not making a good faith effort to understand something. But hey, let's be sensible, right? In maritime navigation and other sets of rules of the road, it's generally the case that the vessels or vehicles or skiers or whomever that are faster more maneuverable are responsible for avoiding collisions with those who are less maneuverable. I think this is a pretty good rule of thumb. Melinda
Re: draft-moonesamy-ietf-conduct-3184bis
On Saturday, August 31, 2013 22:51:48 S Moonesamy wrote: Hi William, At 21:41 31-08-2013, William McCall wrote: Just one point that irks me a bit about this draft... this draft would imply the violation of the code upon those who do (however inadvertently) are 1) Native English speakers and 2) use slang of some nature (which is quite arbitrary). I'd ask for the original phrasing to be more or less preserved (I see a few wording changes worthwhile) to avoid the implied absurdity. The application of Lars' comment would potentially provide for penalty here, so I think it is worthwhile to fight this point now. The original phrasing is as follows: English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English speakers attempt to speak clearly and a bit slowly and to limit the use of slang in order to accommodate the needs of all listeners. The draft reuses the text. That text could be rewritten as: English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English participants attempt to accommodate the needs of other participants by communicating clearly. That does seem better, but don't all parties have an obligation to attempt to communicate clearly? Scott K
Re: draft-moonesamy-ietf-conduct-3184bis
On 8/31/13 10:15 PM, Scott Kitterman wrote: That does seem better, but don't all parties have an obligation to attempt to communicate clearly? Yes, but ... I think it's particularly incumbent on native English speakers to avoid highly idiomatic or stylized language - English that is not taught to non-native speakers. It may be better to say something along those lines, although I don't think you can go too wrong in remind people to communicate clearly. (This is not entirely unrelated to the seeking consensus issue) Melinda
Re: draft-moonesamy-ietf-conduct-3184bis
Hi Eduardo, At 23:19 31-08-2013, Eduardo A. Suarez wrote: I think both parties have to try to express clearly. Those who do not have the English as their native language should also try to do so. Agreed. What is unbearable to me is that in more than one discussion in a mailing list someone's opinion is censored because misspell their ideas or opinions. I'll try and rephrase the above. In some mailing list discussions a person's ideas or opinions are ignored because the ideas or opinions are either not expressed clearly or the ideas or opinions are not understood. Regards, S. Moonesamy
Re: draft-moonesamy-ietf-conduct-3184bis
Melinda Shore melinda.sh...@gmail.com wrote: On 8/31/13 10:15 PM, Scott Kitterman wrote: That does seem better, but don't all parties have an obligation to attempt to communicate clearly? Yes, but ... I think it's particularly incumbent on native English speakers to avoid highly idiomatic or stylized language - English that is not taught to non-native speakers. It may be better to say something along those lines, although I don't think you can go too wrong in remind people to communicate clearly. (This is not entirely unrelated to the seeking consensus issue) That's true, but the emphasis is in the wrong place. I think the behavior standard is try to communicate clearly. What you describe for native speakers is an example of things that help do that. Scott K
Re: draft-moonesamy-ietf-conduct-3184bis
On 9/1/13, S Moonesamy sm+i...@elandsys.com wrote: Hi Eduardo, At 23:19 31-08-2013, Eduardo A. Suarez wrote: I think both parties have to try to express clearly. Those who do not have the English as their native language should also try to do so. Agreed. What is unbearable to me is that in more than one discussion in a mailing list someone's opinion is censored because misspell their ideas or opinions. I'll try and rephrase the above. In some mailing list discussions a person's ideas or opinions are ignored because the ideas or opinions are either not expressed clearly or the ideas or opinions are not understood. I always think the problem of not understanding a message in IETF is not the fault of the transmitter, but it is the receiver's fault. The receiver SHOULD make more efforts to understand, or send a reply to request clarifications (specially in IETF WGs when discussing technical issues). The fault cannot be the used-language or the way the language is used, but the fault can be low performance of communication or low purpose of such work at receiver end. AB
Re: draft-moonesamy-ietf-conduct-3184bis
On Sun, Sep 1, 2013 at 5:50 AM, Scott Kitterman sc...@kitterman.com wrote: I think it's particularly incumbent on native English speakers to avoid highly idiomatic or stylized language - English that is not taught to non-native speakers. It may be better to say something along those lines, although I don't think you can go too wrong in remind people to communicate clearly. (This is not entirely unrelated to the seeking consensus issue) That's true, but the emphasis is in the wrong place. I think the behavior standard is try to communicate clearly. What you describe for native speakers is an example of things that help do that. I think Scott has put this perfectly, and it's exactly right. The main point is clear communication. Everything else is advice about how to achieve that. On Sun, Sep 1, 2013 at 9:47 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: I always think the problem of not understanding a message in IETF is not the fault of the transmitter, but it is the receiver's fault. The receiver SHOULD make more efforts to understand, or send a reply to request clarifications (specially in IETF WGs when discussing technical issues). The fault cannot be the used-language or the way the language is used, but the fault can be low performance of communication or low purpose of such work at receiver end. I agree that the receivers should (and generally do, in my observation, but see below) try hard to understand the transmitter. That said, I can assure you that if I should try to communicate with you in your native language, all fault in the total communication failure that would ensue would be mine. We're all individuals, and we have different tolerance levels -- some of us are more patient than others in trying to understand. That said, this is also a collaborative environment, where everyone needs to do her part. Native speakers need to use a level of English that's likely to be accessible to non-natives, and to do the best they can to understand what others are saying. Non-native speakers need to do what they can to improve their English skills. Everyone has responsibility. Barry
Re: draft-moonesamy-ietf-conduct-3184bis
On 9/1/2013 9:08 AM, Barry Leiba wrote: I think Scott has put this perfectly, and it's exactly right. The main point is clear communication. Everything else is advice about how to achieve that. Both are needed. Especially for a topic like this. That is, for each point, the principle or concept needs to be stated, but then there need to be concrete, behavioral examples. If the document only cites concepts or principles or other terms of abstraction, each of us is likely to interpret them /very/ differently. Especially for a topic like this. Worse, even if we interpret them in the same way, we might not understand what behaviors to attempt or to avoid, since that often requires some understanding of the differences between cultures and people. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: draft-moonesamy-ietf-conduct-3184bis
Hi Eduardo, At 08:44 01-09-2013, Eduardo A. Suárez wrote: the problem is that when one is arguing against the opinion of another person, it is very easy for the recipient to respond you do not write well and I do not understand and so disqualify his opponent. You do not write well is not a reason to reject an opinion. I do not understand is also not a reason to reject an opinion. Please note that, in theory, person Y (see opponent in the above) cannot disqualify the person X. It does happen in practice as people do not use the process which is supposed to prevent all that from happening. Another problem is that it is difficult to know how to use the process. Speaking for myself, it is understandable that anyone in that situation will find it unbearable. I think that it would be good if something which brings results is done about it this year. Regards, S. Moonesamy
Re: draft-moonesamy-ietf-conduct-3184bis
On 02/09/2013 04:22, Dave Crocker wrote: On 9/1/2013 9:08 AM, Barry Leiba wrote: I think Scott has put this perfectly, and it's exactly right. The main point is clear communication. Everything else is advice about how to achieve that. Both are needed. Especially for a topic like this. That is, for each point, the principle or concept needs to be stated, but then there need to be concrete, behavioral examples. If the document only cites concepts or principles or other terms of abstraction, each of us is likely to interpret them /very/ differently. Especially for a topic like this. Worse, even if we interpret them in the same way, we might not understand what behaviors to attempt or to avoid, since that often requires some understanding of the differences between cultures and people. That also applies to the listener. We should advise people to allow for cultural differences and language differences when listening or reading. Is this exchange from 2004 rude or not? I believe we are off-topic here. You are off-topic from the beginning. Brian
Re: draft-moonesamy-ietf-conduct-3184bis
On Aug 31, 2013, at 2:02 PM, Melinda Shore melinda.sh...@gmail.com wrote: It seems like this would be a good time for an update. A few comments: . I think there are a few things that we've been taking for granted that everybody knows, because they did, but that may not longer be the case and consequently they should be made explicit. One that really popped out at me while reading this is that we may need to be clearer that people are participating in the IETF as individuals and contributions are evaluated in that light . I'd like to see some mention of consensus-seeking behavior; that is to say, we make decisions on the basis of rough consensus and so the goal of discussion should be to build consensus rather than to win. . I'm not 100% comfortable with the concept of violating guidelines . I think it was a good idea to remove text that could be discouraging to new participants. I think it would be useful to point out that there is a big difference between getting a draft published as an RFC and getting the proposal deployed. The point of the IETF process is that it provides an opportunity to build the consensus necessary to deploy the proposal. The consensus is the real product, the documents are secondary. Which is why I find the folk who work as consultants claiming to 'grease the skids' of IETF process and get documents through are doing their clients and the community a disservice. Yes, it is possible to get a document published through the backdoor. But doing business that way misses the opportunity to build consensus. It is also the case that some consensus matters more than others. A proposal cannot be deployed without the support of people who write code and operate infrastructure that must be changed. So people who work to effect a back room carve up that cuts those people out of the process are wasting everyone's time
Re: draft-moonesamy-ietf-conduct-3184bis
On 8/31/2013 11:02 AM, Melinda Shore wrote: . I'd like to see some mention of consensus-seeking behavior; that is to say, we make decisions on the basis of rough consensus and so the goal of discussion should be to build consensus rather than to win. +10. Might be worth referencing Pete Resnick's draft; at this point, casting it as one person's 'exploration' of the concept might avoid taking it as official, while still treating it as useful. By way of operationalizing the idea of discussing-to-build-consensus might be emphasizing both explanation -- to help people understand a view -- and modification -- to adjust the view based on feedback. A characteristic of talking to win, rather than explore, is having a very rigid manner of making comments, essentially only re-stating a point. By contrast, real discussion incorporates comments being made, rather than merely seeking to refute them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: draft-moonesamy-ietf-conduct-3184bis
Pete, what is that draft waiting on before becoming an Informational RFC?
Re: draft-moonesamy-ietf-conduct-3184bis
At 11:02 31-08-2013, Melinda Shore wrote:
It seems like this would be a good time for an update. A few
comments:
. I think there are a few things that we've been taking for
granted that everybody knows, because they did, but that
may not longer be the case and consequently they should be
made explicit. One that really popped out at me while
reading this is that we may need to be clearer that people
are participating in the IETF as individuals and
contributions are evaluated in that light
Yes.
. I'd like to see some mention of consensus-seeking behavior;
that is to say, we make decisions on the basis of rough
consensus and so the goal of discussion should be to build
consensus rather than to win.
As a quick reply, it may be possible to put that under Item 2 in
Section 2. My preference would be to pick a comment from Ted Lemon {1]:
Not trying to figure out if what they said meaningfully contradicts your
own position, and not making a sincere effort to determine if they might be
correct in contradicting your position.
and use the above to mention sincere effort.
. I'm not 100% comfortable with the concept of violating
guidelines
I added that based on a comment from Lars Eggert [2]. The word
breach may be more appropriate. I should have used the word
consequences for Appendix B.
. I think it was a good idea to remove text that could be
discouraging to new participants.
There was a comment from Lars Eggert [3]:
'when you begin to participate in a WG, maybe approach the chairs or
longer-term participants in order get a view on whether the issues
you wish to discuss fit the current work of the group.
Rationale: I HAVE seen newcomers raise issues that were either outside
the scope, or raise them in ways that got them a bad reception, and a
little caution about how to get the best result is IMO good.'
My preference is for that to be part of the Newcomers tutorial and/or
the Tao instead of a guideline for conduct.
At 11:15 31-08-2013, Phill wrote:
I think it would be useful to point out that there is a big
difference between getting a draft published as an RFC and getting
the proposal deployed.
The point of the IETF process is that it provides an opportunity to
build the consensus necessary to deploy the proposal. The consensus
is the real product, the documents are secondary.
It would be better to discuss the above as part of the tutorial material.
It is also the case that some consensus matters more than others. A
proposal cannot be deployed without the support of people who write
code and operate infrastructure that must be changed. So people who
work to effect a back room carve up that cuts those people out of
the process are wasting everyone's time
Proposals which do not have the support of the people who write the
code tend to be ignored by the people who write the code.
At 11:15 31-08-2013, Dave Crocker wrote:
Might be worth referencing Pete Resnick's draft; at this point,
casting it as one person's 'exploration' of the concept might avoid
taking it as official, while still treating it as useful.
My preference is to use sincere effort. I'll wait for Pete Resnick
to argue why his draft should be referenced. :-)
By way of operationalizing the idea of discussing-to-build-consensus
might be emphasizing both explanation -- to help people understand a
view -- and modification -- to adjust the view based on feedback.
I think that it would be good to have a discussion of that draft when
Pete Resnick says that it is ready for discussion.
A characteristic of talking to win, rather than explore, is having a
very rigid manner of making comments, essentially only re-stating a
point. By contrast, real discussion incorporates comments being
made, rather than merely seeking to refute them.
The problem may be that it is not clear whether the point will be
considered as valid. There may be a view that restating a point is
useful or else the point will be noticed. In a long thread some
points do get missed. I'll mention an interesting comment:
I almost always get at least some private responses, and they inflict
discomfort often enough for me to not enjoy this communication mode
It is not possible to have a real discussion if people do not feel
comfortable to discuss.
Regards,
S. Moonesamy
1. http://www.ietf.org/mail-archive/web/ietf/current/msg81864.html
2. http://www.ietf.org/mail-archive/web/diversity/current/msg00222.html
3. http://www.ietf.org/mail-archive/web/diversity/current/msg00209.html
4. http://www.ietf.org/mail-archive/web/diversity/current/msg00243.html
Re: draft-moonesamy-ietf-conduct-3184bis
Along with the other recent drafts for streamlining the RFC process, I
get the feeling even this new drafting on conduct is simply going to
be a new rubber stamping tool to shut down the process of due diligent
engineering discussions, required cross areas reviews, including
increasing conflict of interest concerns.
There is a lost of engineering diversity when there is a lack or lost
of industry representation. Folks who shy away, turned off or
excommunicated based on leveraging conduct policies, we get a behavior
I call Consensus by Osmosis -- rough consensus, higher potential for
appeals and huge LC debates.
Too much rough consensus conclusions left to the WGLC and IETF LC that
should and can be worked out before hand.
Ideally, I would like to see new external APPEAL-LIKE paths
(Instant Replay Timeouts viewed by people in the booths) to help,
settle, minimize serious issues in a WG before WGLC and IETF LC begins.
Perhaps this draft should has some statements about what is expected
of the project leaders in the area of processing participant inputs.
I think the draft should also define or describe:
- Participants
- Individuals
- Project Leaders (AD, CHAIRS, EDITORS?)
Ideally, proper professional conduct should include an expectation the
leaders will be not be ignoring participants, individuals, industry
peers and vice versa, of course.
--
HLS
On 8/31/2013 3:58 PM, S Moonesamy wrote:
At 11:02 31-08-2013, Melinda Shore wrote:
It seems like this would be a good time for an update. A few
comments:
. I think there are a few things that we've been taking for
granted that everybody knows, because they did, but that
may not longer be the case and consequently they should be
made explicit. One that really popped out at me while
reading this is that we may need to be clearer that people
are participating in the IETF as individuals and
contributions are evaluated in that light
Yes.
. I'd like to see some mention of consensus-seeking behavior;
that is to say, we make decisions on the basis of rough
consensus and so the goal of discussion should be to build
consensus rather than to win.
As a quick reply, it may be possible to put that under Item 2 in
Section 2. My preference would be to pick a comment from Ted Lemon {1]:
Not trying to figure out if what they said meaningfully
contradicts your
own position, and not making a sincere effort to determine if they
might be
correct in contradicting your position.
and use the above to mention sincere effort.
. I'm not 100% comfortable with the concept of violating
guidelines
I added that based on a comment from Lars Eggert [2]. The word
breach may be more appropriate. I should have used the word
consequences for Appendix B.
. I think it was a good idea to remove text that could be
discouraging to new participants.
There was a comment from Lars Eggert [3]:
'when you begin to participate in a WG, maybe approach the chairs or
longer-term participants in order get a view on whether the issues
you wish to discuss fit the current work of the group.
Rationale: I HAVE seen newcomers raise issues that were either
outside
the scope, or raise them in ways that got them a bad reception, and a
little caution about how to get the best result is IMO good.'
My preference is for that to be part of the Newcomers tutorial and/or
the Tao instead of a guideline for conduct.
At 11:15 31-08-2013, Phill wrote:
I think it would be useful to point out that there is a big
difference between getting a draft published as an RFC and getting
the proposal deployed.
The point of the IETF process is that it provides an opportunity to
build the consensus necessary to deploy the proposal. The consensus
is the real product, the documents are secondary.
It would be better to discuss the above as part of the tutorial material.
It is also the case that some consensus matters more than others. A
proposal cannot be deployed without the support of people who write
code and operate infrastructure that must be changed. So people who
work to effect a back room carve up that cuts those people out of
the process are wasting everyone's time
Proposals which do not have the support of the people who write the
code tend to be ignored by the people who write the code.
At 11:15 31-08-2013, Dave Crocker wrote:
Might be worth referencing Pete Resnick's draft; at this point,
casting it as one person's 'exploration' of the concept might avoid
taking it as official, while still treating it as useful.
My preference is to use sincere effort. I'll wait for Pete Resnick
to argue why his draft should be referenced. :-)
By way of operationalizing the idea of discussing-to-build-consensus
might be emphasizing both explanation -- to help people understand a
view -- and modification -- to adjust the view based on feedback.
I think that it would be good to have a discussion of that draft when
Pete Resnick
Re: draft-moonesamy-ietf-conduct-3184bis
Hi Hector, At 14:50 31-08-2013, Hector Santos wrote: Along with the other recent drafts for streamlining the RFC process, I get the feeling even this new drafting on conduct is simply going to be a new rubber stamping tool to shut down the process of due diligent engineering discussions, required cross areas reviews, including increasing conflict of interest concerns. There is a lost of engineering diversity when there is a lack or lost of industry representation. Folks who shy away, turned off or excommunicated based on leveraging conduct policies, we get a behavior I call Consensus by Osmosis -- rough consensus, higher potential for appeals and huge LC debates. I don't find appeals to be a problem. I don't find huge Last Call debates to be a problem. Unpleasant behavior is a problem as it creates an unworkable climate. I don't think that it is possible to build consensus in such circumstances. Lars Eggert made the following comment: I actually WANT this draft to talk about the CONSEQUENCES (posting rights getting taken away, personal attendance made impossible, etc.) of not following the code of conduct! I think that would be by FAR the most impactful addition we could make. Some of the above is already possible (see Appendix B). Anyone having concerns about conflict of interest can raise the concerns. This draft does not prevent that from happening. This draft is not about cross-area reviews. Perhaps this draft should has some statements about what is expected of the project leaders in the area of processing participant inputs. I think the draft should also define or describe: - Participants - Individuals - Project Leaders (AD, CHAIRS, EDITORS?) The roles are discussed in RFC 2418. Regards, S. Moonesamy
Re: draft-moonesamy-ietf-conduct-3184bis
On 08/31/2013 09:52 PM, S Moonesamy wrote: Lars Eggert made the following comment: I actually WANT this draft to talk about the CONSEQUENCES (posting rights getting taken away, personal attendance made impossible, etc.) of not following the code of conduct! I think that would be by FAR the most impactful addition we could make. Some of the above is already possible (see Appendix B). Just one point that irks me a bit about this draft... this draft would imply the violation of the code upon those who do (however inadvertently) are 1) Native English speakers and 2) use slang of some nature (which is quite arbitrary). I'd ask for the original phrasing to be more or less preserved (I see a few wording changes worthwhile) to avoid the implied absurdity. The application of Lars' comment would potentially provide for penalty here, so I think it is worthwhile to fight this point now. I promise I'll try not to use my generally unintelligible speech. --WM
Re: draft-moonesamy-ietf-conduct-3184bis
Hi William, At 21:41 31-08-2013, William McCall wrote: Just one point that irks me a bit about this draft... this draft would imply the violation of the code upon those who do (however inadvertently) are 1) Native English speakers and 2) use slang of some nature (which is quite arbitrary). I'd ask for the original phrasing to be more or less preserved (I see a few wording changes worthwhile) to avoid the implied absurdity. The application of Lars' comment would potentially provide for penalty here, so I think it is worthwhile to fight this point now. The original phrasing is as follows: English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English speakers attempt to speak clearly and a bit slowly and to limit the use of slang in order to accommodate the needs of all listeners. The draft reuses the text. That text could be rewritten as: English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English participants attempt to accommodate the needs of other participants by communicating clearly. Regards, S. Moonesamy
