community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <humbed...@apache.org>
Subject Re: on "meritocracy"
Date Fri, 29 Mar 2019 20:35:57 GMT
+0.999 (I think this is a great idea, and I'd love to be a part of it, 
contribute with my insights from the various under-represented 
categories I fall into and mistakes I've learned over the past years, 
but unsure how much time I can devote at present).

It will be an interesting journey, and I'm curious to see how we'll 
"sell" it to projects. On one hand, we strive for as much independence 
as possible, on the other hand, we have a set of commonalities and 
governance that fits over - a delicate balancing act.

I haven't spoken up earlier due to travel and getting set up in a new 
country, but...we really suck at this stuff, mainly because we (falsely) 
assume that "no judgment based on X/Y/Z" means leveling the playing 
field, which is not the case. The playing field is *heavily* skewed from 
the get go, and through our inaction we have been maintaining that skew, 
claiming that neutrality will get us where we want. All it gets us is 
stupid virtue signaling and very little towards any of our goals.

While we are vendor neutral, we should not be people neutral, we should 
not be community neutral. Community over Code should mean something, and 
not just be an empty feel-good phrase that looks cool on a tin of mints. 
It should mean more than "we treat everyone as equal....if they can just 
get over these 5,000 other hurdles first".

On 29/03/2019 11.28, Griselda Cuevas wrote:
> Yes! This is exciting. I'd like to be part of the mailing list, and I agree
> that when there's a product encoded in the efforts. the cadence become
> stronger.
> 
> Here's my proposed list of deliverables by work stream:
> 
> *Diagnostic*
> 1) Revamp the 2016 contributor survey
> 2) Launch 2019 Survey (I can do this)
> 3) Analyze results and identify actionable next steps (based in pain
> points, strengths, opportunity areas, etc.)
> 4) Share results & recommendations w/ community
> 
> *Working towards improvement*
> *I can own this work stream and I need more volunteers, I commit to give
> monthly reports. D&I in OSS is part of my day-to-day job, so that's a
> guarantee I'll deliver on it. I also love the topic so I can also dedicate
> personal time to this effort. *
> 1) Curate a list of experts in D&I
> 2) Evaluate possible vendors and select the best fit
> 3) Outline statement of work (define project req.)
> 4) Hire vendor (Due diligence by the ASF)
> 5) Kick-off consulting work, focused on findings from survey.
> 
> *Embedding D&I at the ASF*
> *I want to be part of this. *
> 1) Define purpose, values and objectives for a D&I council
> 2) Define what structure makes more sense
> 3) Work on formalizing the council
> 4) Make the survey the measurement for council's impact YoY
> 
> If you like it, I'm happy to create a Jira board to track efforts.
> 
> 
> On Fri, 29 Mar 2019 at 09:08, Sam Ruby <rubys@intertwingly.net> wrote:
> 
>> On Fri, Mar 29, 2019 at 11:37 AM Griselda Cuevas
>> <gris@google.com.invalid> wrote:
>>>
>>> Another thing we should consider is creating a D&I council, PMC, working
>>> group (or something alike) for the ASF, and I'd love to be part of it.
>>>
>>> Now, I have to share my feelings with discussions on this list.
>> Sometimes I
>>> struggle to understand when a conversation is ready for action. I feel
>> like
>>> I've seen so many great ideas, and I don't have visibility into when they
>>> start to happen or when I should start working on things. This time I'm
>>> offering to lead... so how could I do it?
>>
>> TL;DR: identify a list of tangible deliverables, and I'll help you
>> make it happen.
>>
>> Longer answer:
>>
>> Organizationally, this could be one of the things that is done under
>> the comdev umbrella, it could be something that reports to the
>> president, or it could be something that reports to the board.
>>
>> The third option requires a board resolution.  The middle option is
>> less clear, but in such cases we err on the side of clarity so a board
>> resolution would be prepared.  No board interaction is required for
>> the first option, though a notification in the next board report would
>> be in order.
>>
>> Operationally, this would start pretty much the way everything starts
>> at the ASF: with the creation of a mailing list.  What this will be is
>> a quieter place where people who actually want to do the work get
>> together and make it happen.  I will caution you that often times,
>> those people don't show up, and this ultimately means that it becomes
>> a place to ideas go to die.  And I will say that similar efforts have
>> died this way in the past.
>>
>> Part of what makes PMCs work is that they have a tangle product (code)
>> and deliverables (releases).  This helps keep things focused.
>>
>> Outside of the Code of Conduct, focus is not a word I would use to
>> characterize most of the discussions to date on diversity.  We need to
>> fix that.
>>
>> So... if we (and by that I'm specifically looking for volunteers) can
>> identify tangible work products and there is a commitment to provide
>> written monthly status reports detailing progress towards the
>> production of those work products, I am prepared to support the
>> creation of an officer and committee responsible.  I don't believe
>> that this committee needs board authority (at least not yet), and Ross
>> and I both clearly are interested in making this work.  This leads me
>> to recommend a path of the creation of a President's committee.
>>
>> Circling back, board resolutions are generally evaluated monthly (out
>> of band is possible, but there is no reason here to force the issue).
>> The schedule is here:
>>
>> https://svn.apache.org/repos/private/committers/board/calendar.txt
>>
>> While shooting for April is definitely possible, I would recommend
>> shooting for May.  And the setting up of a mailing list doesn't need
>> to wait for the board resolution - if there is sufficient progress, I
>> can ask the infrastructure team to make it happen.
>>
>> - Sam Ruby
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org


Mime
View raw message