community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <Ross.Gard...@microsoft.com>
Subject RE: ombudsman@ (was Encouraging More Women to Participate on Apache Projects?)
Date Sun, 29 May 2016 22:06:01 GMT
Yes its positive and I've supported it every step, including stating whatever folks decide
is best.  I'm just saying that the kind of reporting you hope for is unlikely to materialize.



Sent from my Windows 10 phone



From: Joseph Schaefer<mailto:joe_schaefer@yahoo.com.INVALID>
Sent: Sunday, May 29, 2016 12:03 PM
To: dev@community.apache.org<mailto:dev@community.apache.org>
Cc: Joseph Schaefer<mailto:joe_schaefer@yahoo.com.INVALID>
Subject: Re: ombudsman@ (was Encouraging More Women to Participate on Apache Projects?)



So whittling down the access to this information from 600 odd members to a handful of people
isn't a positive step Ross?  We can certainly debate the necessity for an ombudsman alias
but that has little to do with the benefits of having a collaborative team of people to deal
with this.

Keep in mind Ross that your own expertise in this matter is limited to your own direct experiences-
we as an org have absolutely no insight into how well you have done in this capacity.  Again
we should look at the facts like retainment and satisfaction of the reporter- what we're doing
isn't enough if the person just winds up walking away from the asf post hoc.

The org has not paid for your training in this matter, and your business training from dealing
with sexual harassment issues at work does not directly translate because there are no employees
here at the asf.  Trust me, I've sat through those same dull meetings myself- it's more about
what not to do to avoid a federal case being filed against the company.

I too have some experiences dealing with other students being sexually harassed by their professors,
so I'm not particularly ignorant of the surrounding issues as to why complaints are filed
to whom and what sorts of remedies are typically desired.  In my capacity as graduate student
representative, despite having a very close relationship with the department chair I never
came across a reporter willing to authorize me to share their report with the chair.  They
always wanted to keep it informal and low key- at best I was asked to confront the professor
in question that I was aware of what was going on with an anonymous person.

What I'm suggesting is that these volunteers discuss directly with the reporters the options
available, and that includes every level of escalation, even to other ombudsman.  This doesn't
seem particularly difficult to grasp, and allows a less experienced volunteer to usher in
advice and support from the rest of the team.

Sent from my iPhone

> On May 29, 2016, at 2:41 PM, Ross Gardler <Ross.Gardler@microsoft.com> wrote:
>
> I don’t think you’ll see that benefit. Privacy and safety from repudiation is a critical
factor. You don't get that with a group sharing experiences and reports. In some cases I have
agreed never to reveal the fact a complaint was made. That’s why I have only provided estimated
counts. I don’t want to go back and count (in fact I don’t even keep the emails in some
cases).
>
>
>
> I'm not saying a group is bad, more choice is good. All I'm saying is that the primary
goal of this focused activity is to deal with the specifics and thus extracting generalities
in small numbers and non-specific summaries of unique situations is not so helpful.
>
>
>
> A more important goal, in the foundation rather than individual sense, is to deal with
the root cause and make the approach being discussed here unnecessary.
>
>
>
> Sent from my Windows 10 phone
>
>
>
> From: Joseph Schaefer<mailto:joe_schaefer@yahoo.com.INVALID>
> Sent: Sunday, May 29, 2016 10:56 AM
> To: dev@community.apache.org<mailto:dev@community.apache.org>
> Subject: Re: ombudsman@ (was Encouraging More Women to Participate on Apache Projects?)
>
>
>
> Also the reasoning about avoiding one man shows for software projects applies equally
well to our ingress reporting strategy.  Right now the only person who has acquired any substantial
real word experience dealing with such reports is Ross, and perhaps a few other individuals
who have proxied reports to him on behalf of another.  Ross won't be president forever, and
hence won't be the perpetual ultimate point of contact for abuse reports, should we still
consider that a necessity.
>
> Hence saddling this responsibility to a small team has all the social advantages that
a collaborative group of developers has over a one man effort, from both a survivability standpoint
and a performance standpoint.
>
> Sent from my iPhone
>
>> On May 29, 2016, at 1:17 PM, Joe Schaefer <joe_schaefer@yahoo.com.INVALID>
wrote:
>>
>> No the president is definitely not part of the problem Niclas.  We're discussing
the delivery mechanism for the most part, as well as reasoning about why some people insist
on having an officer listed as the "ultimate" reporting mechanism.
>>
>>
>>
>> My own experience dealing with sexual harassment reports when I was in graduate school
is that the reporters felt more comfortable reporting to people like me who had relatively
little formality in our power or position, because what they were looking for was not a formal
reprimand, but simply to have the misbehavior stopped, without risk of retribution towards
the reporter.  The higher you go up the formal ladder, the less likely you will be successful
from the reporter's standpoint in achieving a positive outcome "from their perspective". 
 Again it's about what's in the reporter's best interests: sometimes all they want is a shoulder
to cry on, and some empathy for their plight.  If we can positively change the situation for
the better that's great, but it certainly doesn't require a formal title at Apache to achieve
that goal, most of the time.  But when it does, that can always inform the discussion with
the ombudsperson instead of being the starting point for a report.
>>
>>
>>
>> On Friday, May 27, 2016 6:17 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
>>
>>
>> Is a president-private@ mail forward out of the question? If the president
>> is part of the problem, then inform to send to board-private@ instead?
>>
>> Niclas
>>
>> On Fri, May 27, 2016 at 8:25 AM, Roman Shaposhnik <roman@shaposhnik.org>
>> wrote:
>>
>>> On Thu, May 26, 2016 at 5:20 PM, Joe Schaefer
>>> <joe_schaefer@yahoo.com.invalid> wrote:
>>>> Roman,
>>>> I've been beating the archiving problem with president@ like a dead
>>> horse for the past week- what
>>>> on earth have you been reading to avoid that reality?
>>>
>>> Archiving per se is not a problem. If the archive is only available to
>>> the board I'm border line ok with that.
>>> What I didn't know (and it didn't come up in your emails) is that
>>> there could be other folks having access
>>> to the content of president@ who may or may not be on the board.
>>> That's a big, huge problem.
>>>
>>>> Furthermore, I doubt president@ has an associated qmail owner file,
>>> which means any addresses listed in that alias that go to domains whose
>>> mail servers do strict SPF checks will BOUNCE email from major email
>>> providers who publish such rules, and those bounce mails may wind up being
>>> DROPPED by Apache's qmail server since it's attempt to deliver the bounce
>>> mail back to the sender may also be REJECTED by the original sending domain.
>>>
>>> That is also a good point.
>>>
>>>> All of this leads to problems that, while some are fixable, others are
>>> simply not.
>>>> We need a better strategy, and it should be collaborative rather than
>>> dictatorial.
>>>
>>> Not sure what you mean, but as I said ideally I'd like it to be an
>>> alias for an officer
>>> appointed by the board. That's my MVP. What Shane suggested builds up on
>>> that
>>> and may provide an even better solution.
>>>
>>> Thanks,
>>> Roman.
>>
>>
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fzest.apache.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c9759d515c87f4d91e6ce08d387ea8d09%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2u6lzVmy3y9prPlnDUvhuaZGEFV%2fOEherBdEsDStByA%3d
- New Energy for Java
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message