Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 03/01/15 15:42, Adam D. Ruppe via Digitalmars-d wrote: I've heard this a few times before over the years, and it hasn't happened yet. Perhaps we're not growing at the the necessary rapid rate, but I think new people try to blend into what they see other people doing, so as long as at any given time, the majority of us behave fairly well, it will stay that way. I agree with what you're saying about a fair process and I don't think some guidelines about how to deal with trouble would be bad, even if it is as simple as please don't feed the trolls or even turn the other cheek*. But I also think we're doing OK as it is right now and have been for a lot of years and probably will be for many years more. I think that's fair enough. Bear in mind that what I actually proposed was a guideline for one quite specific scenario, i.e. how to handle people asking for features, proposing ideas, and so on, who were not willing or able to step up and deliver them. I'd be happy if that principle was simply accepted by core community members (it seems to have been) and promulgated by example and polite nudges.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 1 Jan 2015 18:46, Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com wrote: On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote: I did want to say something about this. I've given a close read to the Lost a new commercial user this week thread, through and through. It seems I've identified a problem that belongs to us. (Us is a vacuous term meaning the leaders of the D community). My initial read of your complaint went like this: it's about Windows (I don't even have an installation), it's about vibe.d (haven't used it yet), and it's also discussing documentation (which is something we can indeed improve and I know how to). So a large part of the problem wasn't even mine to work on. Others harbored similar perceptions. The corollary has been that essentially you're asking them to stop working on D aspects they do care about and start working on D aspects you and others care about - all on their free time. A few thoughts on this. (This turned a bit longer than expected in the writing, so I've highlighted some TL;DR sections to highlight key ideas.) I think that one of the most common sources of community friction in open source is people mistaking being _asked_ to work on something that someone else cares about, for being _expected_ to do so. That's very unfortunate, because it means that all too often people will come into a community, full of enthusiasm for this new thing they've discovered, make some suggestions, and get shot down like they're some sort of plague carrier. (The D community is pretty good at not doing this with newcomers, but deals less well with people repeatedly raising ideas; more on that in a moment.) Obviously, there are people who display an enormous sense of entitlement, who are rude or just throw demands around in a very arrogant way. But simply saying, I want this, I need this, or I think this would be a good idea should not IMO be a trigger for criticism or hostility. Most of the time, people do understand the fundamental constraints of a volunteer community with limited resources, and what they are interested in having is either acknowledgement of a good idea or use-case (preferably with something getting onto a TODO list, but not necessarily with any priority), or feedback that helps them understand alternative ways to solve their problem. (Caveat: it matters whether the problem is actually solved, or just worked around.) I've stopped here (I'm reading from a phone and travelling), but some thoughts come to mind when it comes to persistent offenders/questions. 1. DIPs should be process of getting a new feature / breaking change through - not the ML. People who want changes strong enough should be encouraged to raise one. 2. Why does D not do X? And other frequent questions should go in a FAQ with a clear answer. This hopefully isn't the rule but I sense sometimes the reason certain things come up again and again are because either of the following: a. Responses vary or change over time. So the original reason and motivation for rejection gets lost. b. There is no official rejection stamp for ideas that spring up from the ML compared to DIPs. Having this in a FAQ serves the purposes of both (a) and (b). 3. Bounties were supposed to address some aspects of feature driven goals. I don't think this works in practice but the thought process seemed sound, in terms of: a. Someone has an idea and raises it in the ML. b. A DIP is created, along with a bugzilla report and bounty. c. More bounties that go in drives popularity and the likelihood of a PR being raised to implement the DIP. I don't have an alternate proposal to this, but I recognize that upvotes in bugzilla don't drive incentives either. Though you may have raised some good points on these. :) Iain.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 1/2/2015 11:31 PM, Rikki Cattermole wrote: On 3/01/2015 7:55 p.m., Andrei Alexandrescu wrote: On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote: That said, I don't see any pressing need for something formal at this point in time. Some friendly suggestions, guidelines or advice -- that's another thing and doesn't need to be provided in a formal way. So now should I close https://issues.dlang.org/show_bug.cgi?id=13928 that I just created? :o) -- Andrei Yes. Please don't. While I understand Walters position to not formalizing a set of do's and dont's, we do still need something even if its just a mantra shown if a cookie is not present in the NG web interface. It can be as simple as, this is a professional communication facility for furthering the D programming language. Please respect the goals of the community. No evidence we need that, and if we did, that it would be effective. Explained in a previous post.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On Saturday, 3 January 2015 at 00:06:10 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote: Obviously D does not have such a problem right now, but as the number of people active on the forums grows, there are inevitably going to be more and more instances of people behaving antisocially, and that does in turn make it more important to have some mechanism to ensure they are dealt with fairly and not arbitrarily. I've heard this a few times before over the years, and it hasn't happened yet. Perhaps we're not growing at the the necessary rapid rate, but I think new people try to blend into what they see other people doing, so as long as at any given time, the majority of us behave fairly well, it will stay that way. I agree with what you're saying about a fair process and I don't think some guidelines about how to deal with trouble would be bad, even if it is as simple as please don't feed the trolls or even turn the other cheek*. But I also think we're doing OK as it is right now and have been for a lot of years and probably will be for many years more. * fun fact, a lot of people see the eye for an eye thing as being like a gross cruel and unusual punishment, but at the time, it was actually quite progressive - it put limits on executive power! If the rule is tooth for a tooth, the disciplinarian can't arbitrarily decide to draw and quarter you because you punched his buddy in the face. Goes to what you said about the fair process.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 1/1/15 10:45 AM, Joseph Rushton Wakeling via Digitalmars-d wrote: On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote: I did want to say something about this. I've given a close read to the Lost a new commercial user this week thread, through and through. It seems I've identified a problem that belongs to us. (Us is a vacuous term meaning the leaders of the D community). My initial read of your complaint went like this: it's about Windows (I don't even have an installation), it's about vibe.d (haven't used it yet), and it's also discussing documentation (which is something we can indeed improve and I know how to). So a large part of the problem wasn't even mine to work on. Others harbored similar perceptions. The corollary has been that essentially you're asking them to stop working on D aspects they do care about and start working on D aspects you and others care about - all on their free time. A few thoughts on this. (This turned a bit longer than expected in the writing, so I've highlighted some TL;DR sections to highlight key ideas.) [snip] Good stuff, thanks. Question about this: TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves. The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: You can ask but not demand. What would be an appropriate place to put this? Andrei
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 02/01/15 10:26, Andrei Alexandrescu via Digitalmars-d wrote: Good stuff, thanks. Question about this: I'm glad it seems useful; I wondered after writing if it was a bit too much of a rambling mess :-P TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves. The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: You can ask but not demand. What would be an appropriate place to put this? How about a link at the top of the forum.dlang.org page saying something like, Before posting, please read our _community guidelines_ ? With the page linked to containing advice like the above. I know that there's always been a lot of pride that we've always been able to get along without some kind of code of conduct, but ... well, guidelines are not the same as a code, and anyway, not having guidance just doesn't scale in my experience.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 1/2/2015 1:17 PM, Joseph Rushton Wakeling via Digitalmars-d wrote: How about a link at the top of the forum.dlang.org page saying something like, Before posting, please read our _community guidelines_ ? With the page linked to containing advice like the above. I know that there's always been a lot of pride that we've always been able to get along without some kind of code of conduct, but ... well, guidelines are not the same as a code, and anyway, not having guidance just doesn't scale in my experience. I've been extremely reluctant to have any sort of official conduct code. I prefer a gentle nudge on a case by case basis, and just deleting the posts of incorrigible trolls. Leading by example, implicit expectations of good conduct, and peer pressure can be amazingly effective. A code of conduct that says things like don't harass others, no illegal content, etc. are just pointless, patronizing and frankly insulting. If someone wants to behave badly, is a code of conduct really going to change their mind? Caltech, which I attended, was very influential on me in that it is the only school in the world that has a real honor system. Nobody else has the guts to try it. I've had good success applying the principles of it ever since, and this forum is one of them. Essentially, the default attitude is to trust that people are honest and decent. I don't tell them how to be honest and decent, I just assume that they are. It works amazingly well. (At Caltech, for example, exams are not proctored by institute policy. You can even take time limited tests home with you and do them when you're ready. The number of Fs students get on exams is a pretty good indicator that when they're trusted, they rise to the occasion.) I've noticed that the D community is an unusually honorable and decent group of people. Maybe that's due in some part to implicitly expecting them to be so, or maybe that's my own hubris. But I am extremely unwilling to risk that by posting a code of conduct that assumes people need lessons in how to behave.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 1/2/2015 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote: On 02/01/15 23:50, Walter Bright via Digitalmars-d wrote: That said, I don't see any pressing need for something formal at this point in time. Some friendly suggestions, guidelines or advice -- that's another thing and doesn't need to be provided in a formal way. If it's posted with a link, it's then formal. I handle things on a case by case basis (and there isn't much of it, thankfully). It works well enough. We've got a community here we can be proud of.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 3/01/2015 7:55 p.m., Andrei Alexandrescu wrote: On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote: That said, I don't see any pressing need for something formal at this point in time. Some friendly suggestions, guidelines or advice -- that's another thing and doesn't need to be provided in a formal way. So now should I close https://issues.dlang.org/show_bug.cgi?id=13928 that I just created? :o) -- Andrei Please don't. While I understand Walters position to not formalizing a set of do's and dont's, we do still need something even if its just a mantra shown if a cookie is not present in the NG web interface. It can be as simple as, this is a professional communication facility for furthering the D programming language. Please respect the goals of the community.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves. The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: You can ask but not demand. What would be an appropriate place to put this? Andrei Any kind of main place, for example first page of dlang.org, but not alone. I have suggestion in my mind for a month at least: For D's community is good to formulate something like principles or axiomata. (Because as I see, many discussion goes round and round about similar things). One of those principle may sound like this for example: __D is safe by default and fast when need.__ (This about general design of D, for example about garbage collection). Main page has something like this but in descriptive not rule-provided form. After formulating such maxima many discussion calming itself, because part of ideas will follow global goals and another contradict. In my view such principles have to cover following aspects: design of D (about safety, speed, multiparadigmality, glitchness, smoothness and so on), evolution of D (in such cases breaking change is allowed and about deepness of breakage, phobos and its topics coverage and so on) and community cooperation (yes, it is suggested by Joseph Rushton Wakeling community guidline). IMO discussion about such axiomata (when comunity interesting in) need own topic.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On Fri, Jan 2, 2015 at 7:26 AM, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 1/1/15 10:45 AM, Joseph Rushton Wakeling via Digitalmars-d wrote: On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote: I did want to say something about this. I've given a close read to the Lost a new commercial user this week thread, through and through. It seems I've identified a problem that belongs to us. (Us is a vacuous term meaning the leaders of the D community). My initial read of your complaint went like this: it's about Windows (I don't even have an installation), it's about vibe.d (haven't used it yet), and it's also discussing documentation (which is something we can indeed improve and I know how to). So a large part of the problem wasn't even mine to work on. Others harbored similar perceptions. The corollary has been that essentially you're asking them to stop working on D aspects they do care about and start working on D aspects you and others care about - all on their free time. A few thoughts on this. (This turned a bit longer than expected in the writing, so I've highlighted some TL;DR sections to highlight key ideas.) [snip] Good stuff, thanks. Question about this: TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves. The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: You can ask but not demand. What would be an appropriate place to put this? We could post an FAQ or something FAQ-like every month or so, including things like can I ask for things I want? or what should I post to each forum?. LMB
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 02/01/15 23:50, Walter Bright via Digitalmars-d wrote: I've been extremely reluctant to have any sort of official conduct code. I prefer a gentle nudge on a case by case basis, and just deleting the posts of incorrigible trolls. Yes, I'm aware of that, and I do have a lot of sympathy with your point of view. Leading by example, implicit expectations of good conduct, and peer pressure can be amazingly effective. All very true. A code of conduct that says things like don't harass others, no illegal content, etc. are just pointless, patronizing and frankly insulting. If someone wants to behave badly, is a code of conduct really going to change their mind? As regards the specific provisions you cite, sure, that stuff is almost always annoying and patronizing. But I think that what I was proposing was slightly more subtle. I do think there's a big difference between friendly guidelines, versus a code of conduct. The most obvious is that the former are intended to be helpful advice, not a list of expectations. Caltech, which I attended, was very influential on me in that it is the only school in the world that has a real honor system. Nobody else has the guts to try it. I've had good success applying the principles of it ever since, and this forum is one of them. Essentially, the default attitude is to trust that people are honest and decent. I don't tell them how to be honest and decent, I just assume that they are. It works amazingly well. I agree. However, I think that the ability to rely on an honour system does depend to a certain extent on the numbers of people you are dealing with. One of the benefits of guidelines or codes of conduct is not so much in instructing people what to do, as much as in constraining the leadership or authority figures in an organization to behave fairly and consistently in acting against troublemakers. This becomes quite apparent in some moderated forums where the moderation in practice amounts to What ticks off the current moderator at this particular moment. Such communities are rarely fun to be part of. Obviously D does not have such a problem right now, but as the number of people active on the forums grows, there are inevitably going to be more and more instances of people behaving antisocially, and that does in turn make it more important to have some mechanism to ensure they are dealt with fairly and not arbitrarily. There are also some particular personality traits that can lead people to have problems understanding how their behaviour is impacting on others -- obvious examples are people on some parts of the autistic spectrum or people who are experiencing mental health issues. Firm guidelines can sometimes be helpful here in terms of defining clear boundaries that people can look to when they may not entirely trust their own judgement. They can also be _very_ important in helping to ensure that other community members do not victimise someone who seems to be acting antisocially, but may in fact be experiencing issues that prevent them from realizing how they are coming across. I've noticed that the D community is an unusually honorable and decent group of people. Maybe that's due in some part to implicitly expecting them to be so, or maybe that's my own hubris. But I am extremely unwilling to risk that by posting a code of conduct that assumes people need lessons in how to behave. If you think of it less as an attempt to tell people how to behave, and more of a sanity check for community leaders to think, Hang on, am I right to call out this person for their behaviour?, then a code of conduct can make more sense. In the (hopefully rare) event that a community member does need to be dealt with firmly, it can also be helpful to have something consistent to point to to explain such decisions. That said, I don't see any pressing need for something formal at this point in time. Some friendly suggestions, guidelines or advice -- that's another thing and doesn't need to be provided in a formal way.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
I've been extremely reluctant to have any sort of official conduct code. I prefer a gentle nudge on a case by case basis, and just deleting the posts of incorrigible trolls. Leading by example, implicit expectations of good conduct, and peer pressure can be amazingly effective. Yes, we don't need official forum rules, but we have to agree on the unofficial ones. If people with d street cred step up and tell people if they go overboard everyone will follow. If they point to some official rules, those how break them will just argue that they technically didn't. We have no need for lawyers here.
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 1/2/15 1:17 PM, Joseph Rushton Wakeling via Digitalmars-d wrote: On 02/01/15 10:26, Andrei Alexandrescu via Digitalmars-d wrote: Good stuff, thanks. Question about this: I'm glad it seems useful; I wondered after writing if it was a bit too much of a rambling mess :-P TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves. The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: You can ask but not demand. What would be an appropriate place to put this? How about a link at the top of the forum.dlang.org page saying something like, Before posting, please read our _community guidelines_ ? With the page linked to containing advice like the above. I know that there's always been a lot of pride that we've always been able to get along without some kind of code of conduct, but ... well, guidelines are not the same as a code, and anyway, not having guidance just doesn't scale in my experience. https://issues.dlang.org/show_bug.cgi?id=13928 Andrei
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote: That said, I don't see any pressing need for something formal at this point in time. Some friendly suggestions, guidelines or advice -- that's another thing and doesn't need to be provided in a formal way. So now should I close https://issues.dlang.org/show_bug.cgi?id=13928 that I just created? :o) -- Andrei
Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote: I did want to say something about this. I've given a close read to the Lost a new commercial user this week thread, through and through. It seems I've identified a problem that belongs to us. (Us is a vacuous term meaning the leaders of the D community). My initial read of your complaint went like this: it's about Windows (I don't even have an installation), it's about vibe.d (haven't used it yet), and it's also discussing documentation (which is something we can indeed improve and I know how to). So a large part of the problem wasn't even mine to work on. Others harbored similar perceptions. The corollary has been that essentially you're asking them to stop working on D aspects they do care about and start working on D aspects you and others care about - all on their free time. A few thoughts on this. (This turned a bit longer than expected in the writing, so I've highlighted some TL;DR sections to highlight key ideas.) I think that one of the most common sources of community friction in open source is people mistaking being _asked_ to work on something that someone else cares about, for being _expected_ to do so. That's very unfortunate, because it means that all too often people will come into a community, full of enthusiasm for this new thing they've discovered, make some suggestions, and get shot down like they're some sort of plague carrier. (The D community is pretty good at not doing this with newcomers, but deals less well with people repeatedly raising ideas; more on that in a moment.) Obviously, there are people who display an enormous sense of entitlement, who are rude or just throw demands around in a very arrogant way. But simply saying, I want this, I need this, or I think this would be a good idea should not IMO be a trigger for criticism or hostility. Most of the time, people do understand the fundamental constraints of a volunteer community with limited resources, and what they are interested in having is either acknowledgement of a good idea or use-case (preferably with something getting onto a TODO list, but not necessarily with any priority), or feedback that helps them understand alternative ways to solve their problem. (Caveat: it matters whether the problem is actually solved, or just worked around.) TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves. The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: You can ask but not demand. The other observation is that, often, what frustrates core contributors about people coming in with ideas and requests and so on, is that responding to that takes time and effort and often distracts from limited time available to deliver actual work. It can be very, very wearing having to explain to people time and time again why something is a certain way, or to have to make the case yet again why X is not considered a priority, or whatever. Now, in some cases, these problems are self-inflicted. I've encountered core contributors in some communities who simply _could not let go_ of the need to prove someone else wrong, or to explain to the n'th degree why something was not possible. (This interacts very badly with me, because I find it very difficult to let go of a discussion where I feel that I've been misunderstood:-) In other cases I've seen core contributors regularly engage in rudeness or sometimes even virulent personal attacks, and then bemoan how demotivating it is having to deal with belligerent arguments on the mailing lists. Thankfully the D community sees very little of this. More often, it's simply a result of the discrepancy between numbers of contributors and numbers of (verbally active) users -- and it only gets compounded by the feeling that, if people spent half the time contributing that they spent arguing, far more things would get done and the core contributors would have a much easier time of it. IMHO there are two important things to address here. One is to give a lot of priority to entry blockers -- to the things that prevent people from becoming users or contributors. Difficult installation experiences, obscure dependencies, weird or out-of-date tools etc. are all things that are boring but important to address because the work to solve them can pay off massively in terms of how many people are willing to get involved. (D's move to GitHub is a great example.) Obviously volunteer contributors can't be obliged to accept these priorities, but it should be possible to highlight and stress them as
