> 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
