Not directly a response to the below, but very much related to it. If you go to a Node.js conference these days, the very first thing you do is pick up a badge. When you do, they ask you to consider putting on a sticker containing your preferred pronouns. Shortly thereafter you realize that the conference is qualitatively different in terms of inclusion - gender isn't quite a 50/50 split, but I did find myself on more than one occasion seated surrounded by women - north, south, east, west. There also are talks, panels, open discussions on diversity.
There also are noticeably more people with different gender orientations, people of color, etc. Not just in the audience, but also on the stage. When people (generally inadvertent) make a remark that could be considered non-inclusive on a node mailing list, they are generally called on it (and quickly), and promptly apologize, and the apology is promptly accepted. If there are any actions that need to be taken, they are identified and acted upon. Where we, the ASF, are and continue to be is abnormal. The difference from industry norms is statistically significant. And durable. When such topics come up here, the response is contentious and defensive, long winded, and generally without resolution. Yes, you will find women at ASF conferences. Look, there are two over there, and one more on the other side. OK, so there may be some talks where there are more, but there are also some talks where there are less. There must be something that we are doing - or not doing - which is causing all of this. What saddens me is that I don't know what to suggest. Enumerating what we are doing (such as Rich did below) is a good start. But also acknowledging that we are somehow the cause if it - either though action or inaction - is also a necessary first step. - Sam Ruby On Thu, Mar 28, 2019 at 12:48 PM Rich Bowen <rbo...@rcbowen.com> wrote: > > > > On 3/28/19 11:58 AM, Pierre Smits wrote: > > > I find it sad that there are (board) members who keep saying that the > > situation must improve (because there are problems regarding Diversity and > > Inclusion), but when it comes to where it needs to improve (in the projects > > mostly) they also keep saying (here and other threads also in other fora in > > the past) that there is nothing to be done from the Foundation downwards to > > the projects because 'the projects are independent'. > > I am not aware of any board members who have said that. Unless you're > construing my comment in that light. Because that is most definitely not > what I said. > > The Foundation does do stuff "downwards to the projects." We have, in > fact, established a PMC, named "Community Development" which has that as > its charter. > > Furthermore, EVERY SINGLE MONTH, there is at least one (and usually > several) response to a project report, encouraging them to more actively > pursue new committers, lower their bar to entry, actively mentor new > contributors, and so on. > > > > > In my book there is where the view-points of those persons go of in wrong > > directions. Yes, projects are expected to operate independently from > > outside influence. But they can not operate independently from the > > organisation they reside under. In a page (See [1]) of the ASF it is stated > > that 'the board delegates the technical direction of all projects to each > > PMC', but 'are expected to follow corporate policies'. This means that the > > policies can be created at Foundation level, and can be policed (by the > > Board, and/or through delegation by a specific office). If the highest body > > of the Foundation established a strict(er) policy on 'merit awarding' > > and/or 'Diversity & Inclusion' then it is obliged, with regards to these > > policies, to: > > > > 1. ensure that each of the lower level organisational units (OUs like > > projects/offices/departments, etc.) acknowledge and apply such policies > > Yes, we do that. Daily on board@ and monthly in the board meeting. > > > 2. regularly (and independently of the projects and offices) assess the > > adherence to (or compliance with) the policies > > Yes, we do that. Projects report quarterly to the board, and at that > time we review their performance with respect to those policies. > > > 3. actively implement corrective measures when an OU fails to adhere to > > or comply with such policy. > > Yes, we do that too. > > > Mark suggested in a posting earlier that there is something called the D&I > > team that could be tasked with gathering advice from domain experts, and > > advise the President/Board on how to improve this situation. But it seems > > (I have done some searching on ASF pages regarding this D&I team) the team > > has not been established formally and thus no insights on its mission and > > production can be established. Maybe that still needs to happen? Or is it > > flying very low under the radar, or.... ? > > It's call ComDev. This entire thread is about how we're not doing an > awesome job, and can stand to improve. > > > Whatever it may be (visages the D&I team), here are some suggestions that > > may lead to an improved situation: > > > > 1. Communicate (e.g. via the ASF's web site) clearly where contributors, > > who feel they were wronged, can submit complaints; > > For the Incubator, this is documented here - > https://wiki.apache.org/incubator/PodlingBillOfRights > > For the foundation as a whole, it is documented here: > https://www.apache.org/foundation/policies/conduct > > > 2. Treat complaints (and their submitters) seriously and discretely; > > If you have evidence that this has not happened, I encourage you to > report it, as per the above documentation. > > > 3. Have a protocol published so that everybody can learn about what to > > expect and when to expect it. > > I'm not sure what you're asking for here. Can you elaborate on what kind > of "protocol" you're referring to? > > -- > Rich Bowen - rbo...@rcbowen.com > http://rcbowen.com/ > @rbowen > > --------------------------------------------------------------------- > 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
