"don’t see this here" - that's the root of the problem. I was the point of contact for the Code of Conduct for three years. I can assure you the problem exists, in some cases in very extreme ways. You might not see it (perhaps it's not in your projects) or perhaps you are blind to it (that's not an attack on you, I miss it too, I'm part of the problem - white, male, English speaking, imperfect).
I can assure you it exists. It's usually dealt with quietly. For the most part, people are not intending to be exclusionary. In fact they are, usually, offended that someone would see them as being exclusionary, they seek to explain that "that's not what I meant, what I meant was..." [TIP: if someone is gently pointing out an error they are not judging you they are trying to help you see how it is exclusionary, just apologize, thank them and move on] Then they get angry that it's positive discrimination to "censor" them, "why aren't you protecting my right to express an opinion?" is the typical kind of response. [TIP: the CoC applies to everyone equally it is designed to guide us on how to express our opinion in a way that is inclusive of all] After a (typically long) conversation explaining how they can make their point without being exclusionary they are usually begrudgingly grateful and they can be seen trying to modify their behavior. [TIP: it's an awesome feeling when someone sees you making an effort and thanks you for it, plus it's good for your project!] As I've posted elsethread I believe that many of us are simply unaware of how our social norms are exclusionary. I believe the softly, softly approach to helping people realize this is more effective. However, the softly, softly approach has the negative side effect of making the issues less visible. In my experience this is necessary since many people affected by this are not willing to be singled out by publicly calling out people. [TIP: always, gently, call out exclusionary behavior you see in F2F meetings - there are very different dynamics there and individuals sometimes need to know people are looking out for them] I ask that everyone reading this far take a moment to think the above through. It means the issues that cause us to have poor diversity are mostly invisible to us. Therefore we assume the problem doesn't exist or isn't as severe as some claim. Thus when someone raises concerns we tell them they are wrong, which is exclusionary in and of itself. [TIP: always assume the other person has a justifiable reason for raising their concern and learn from it. Maybe ask how one might help. If you just can't see it, fine, don't engage. For the sake of our community don't deny the claim. Assume good intent. If you are right and the it's a non-event the thread will die immediately - there is no need to refute it] Wade asks for explicit examples. My experience is that if we point to out an explicit example then someone will attempt to justify it (see above) and we end up in an argument about misinterpretation and censorship without ever getting back to constructive debate from which we can all learn. However, you can look at this thread for quite a number of examples. Another place you can go is the video I shared earlier. There are two points at which I cringe at my clumsy efforts to be inclusive at the very time I'm trying to talk about D&I. Watch it and see if you can spot them. If you can't then why not ask someone in a minority group? Feel free to post your thoughts here - there's problem things I don't see yet. Don't worry about calling me out in public. I have no concerns being singled out. I make mistakes like the rest of us. Even in this thread I've made mistakes (and been called out on it privately so I can continue to improve). I'll try to do better. We all need to do better. A good first step is to accept that there is a problem and ask how we can contribute to fixing it rather than spending time denying it exists. Ross ________________________________________ From: Wade Chandler <wadechand...@apache.org> Sent: Friday, March 29, 2019 8:35 PM To: dev@community.apache.org Subject: Re: on "meritocracy" > On Mar 28, 2019, at 8:34 AM, Naomi Slater <n...@tumbolia.org> wrote: > > On Thu, 28 Mar 2019 at 13:14, Jim Jagielski <j...@jagunet.com> wrote: > >> >>> but in practice, this isn't true. and our committer demographics >>> demonstrate this >> >> Then those PMCs have a f'ed up definition and measure of merit. >> > > but this is true for all PMCs, and indeed our board. we have dismal > representation for non men, non white people, etc, etc, across the whole > organization. so you're saying that our whole organization has a f*ed up > definition and measure of merit. which is precisely my point. and why I > started this thread How would you suggest individuals actually attract diversity in a given cultural context? Software development is inherently a cultural context. Thus, Apache is a sub-context of that. So, in this specific context. On one hand an organization “can” actively keep people out based on personal attributes; intentional negative & bad; don’t see this here; if you do, please give direct links; most will certainly see that the same. On another it “can” actively try to attract more diversity; intentional positive; not sure I see this at Apache. On another it “can” try to attract people who contribute, and within that not have a bias related to any attribute of a person other than they contribute; I see a lot of this at Apache; not bad (evil), also good, not intentionally attracting diversity, but the part that should be kept in mind is it is also good; not seeing this as something to change as something that can be complemented. Given you previously mentioned companies and performance reviews etc; I will suggest part of the problem in those contexts are those reviews are often measuring the wrong things, and not measuring the drivers of the hierarchy of work in which most workers actually exist within an organization; they please the street though. Were they measuring the right things, and this odd dichotomy removed, and the right signaling known to all, i.e. good communication of the things that really matter, it would probably help a lot. I don’t think this can be applied to Apache contributors though; it is really clear the thing that matters; software that works and those making that happen within a legal framework; very different than a company and employee relationship and the motivators for it. > > FWIW, I disagree, wholeheartedly, with the phrase: >> >> the already privileged SUCK at determining who deserves >> "recognition of merit" >> >> I think that is self-serving and a gross and crass generalization >> that does not help in uniting anyone. >> > > self-serving how? if you mean it serves the interests of women and other > marginalized people at this organization, then yes, that is also precisely > my point. this is what we should be doing > Marginalized has a very specific and strong meaning; one of intent. Do you intend to use it per that meaning? Merit as applied in “The Apache Way” rewards those who do work; it serves those who do work. Do you agree with this in principle as a baseline? I find that to be a clear read, and in practice is what I’ve seen for Apache projects. If not, then what should be the measure of reward for one to become a “committer” to a code base? It is something that needs care and feeding, and in many cases, has many dependencies throughout the world, and that’s a big deal. Similar to a company, requiring care and feeding, which regardless of anything else, would not hire someone with the wrong skillset nor record of the right skillset be it experience or a degree. A university, needing the same, as do its students, would not hire a high school burger flipper as a professor either, regardless of demographics and needs; it would not be prudent. These are examples of rewarding applicants of merit without them first having done anything for the particular organization. It seems clear Apache has this same principal, and takes it further to protect the software we all collectively use and depend on; Apache vets more thoroughly by way of actual contributions versus credentials; in this context I’ve not seen abuse of individuals based on anything other than their commitments to a given code base. I don’t know anyone (“virtually" for most) I’ve met at Apache who wears their personal attributes as a badge either, and I say this to suggest it is difficult for me at least to gauge ones physical attributes by those things which I can measure about them in this context; mostly emails, patches, and commits. > it's uncomfortable to confront this fact. but it must be confronted. and > appeals to "uniting people" (i.e. don't upset people or make them confront > their biases or failures) is counter-productive and it won't have any sway > with me Sway? Isn’t that what you are attempting to do though? How about facts. If there is evidence to support what I’m reading as a strong statement, then it should exist. The numbers of people of a given N or X doesn’t prove anything; anecdote at best on face. Messages and specific context where one was impacted by biases attributed to ones personal attributes would be. A given negative vote generally requires some explanation in the NetBeans community as an example. Thus, what specifically are you suggesting folks confront besides the nebulous abstract? If you’re asking people to think about how to attract diversity to projects, and figure out how to do it, and try to take action, then I say good goal, and support it, but given the context, and the reality there is a participation and contribution facet to it, as well as level of energy, time, and other commitments mixed in the nature of OSS contributions, from both the current contributors and anyone who would come to a project, it does have limitations as to the effect such an effort can have. There are a lot of variables at play there, and most of the barriers are not related to some evil agenda; it’s just a lot. > > additionally, how can you disagree with this characterization when (per our > committer demographics) we have *demonstrably* failed to recognize merit in > an equitable way > Where's factual basis other than the demographics themselves; correlation versus causation? It isn’t demonstrable this is a failure to recognize merit or in an equitable way unless you can demonstrate the failure to recognize merit is actually related to or driven by something other than contributors who just happened to come to a project and their contributions; happenstance. Where are those people who came to contribute or to be voted in to project X who have been afflicted or turned away? I think it is something to ask, and fair enough to review, but you’re approaching it in a negative and even divisive way, not a positive one. Who? What? When? Where? (for these bad experiences based on ones attributes). If the population who came to the projects and contributed and wanted to join and be voted in don’t have enough representation of those demographics to begin with, then it suggests an entirely different problem than merit to me; marketing and attraction of diverse people, and that has its own set of variables and problems. In my anecdotes, most folks who come to work on a piece of OSS don't come for much of my perception of your reasoning; they come because they need the software and contribute to it as an artifact of use and vested interest or because it is something to do, and they stumbled onto it; I’ve never personally met any whose priority was beyond this, but I’m sure there are cases. To infer other intent, I don’t know and haven’t seen it. But what I do see in that is a finite number of people who come, contribute, make patches, and then ask for a vote, and that set is certainly much smaller than the finite set of users, and per a project, much smaller than the set of people who come to “some” project at Apache, and that set much smaller than the set of all the other vast and overwhelming number of OSS communities and their users collectively; so a really big set of possibilities. Wade --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
