Re: [DISCUSS] Outreachy framework proposal

[Joan Touzet]

On 2019-06-26 22:39, Patricia Shanahan wrote:> On 6/26/2019 6:43 PM,
Ross Gardler wrote:
> ...
>> The ASF doesn't pay *anyone* to work on our software. There is no
>> discrimination in that. Sure one can argue it creates less opportunity
>> than paying for a few individuals, but that's not the same as
>> discrimination.
> ...
>
> Suppose an agricultural or construction business prohibits the use of
> sunscreen and hats with brims. I am of European origin and live in San
> Diego, so for me to be outside all day without a hat or sunscreen would
> be certain sunburn and a high risk of skin cancer. Nobody is allowed
> sunscreen, so no discrimination.
>
> More realistically, suppose a business requires all employees to wear
> their hair in styles that are not feasible with the naturally tightly
> curly hair that is typical of some areas of Africa. That can either
> prevent some African-Americans from working there or require them to use
> unpleasant and expensive hair straightening chemicals. It's the same
> hair style for everyone, so no discrimination.
>
> (I regard a person liking some hair style and choosing to put time,
> money, and effort into it as very different from being forced to do so
> to get and keep a job.)
>
> Suppose an employer configures all restrooms with very few sit-down
> stalls and many designed-for-men urinals, and limits the time for
> bathroom breaks. If more than a handful of women try to work there the
> lines for the stalls take longer than the break time. It's the same
> bathroom arrangements for everyone, so no discrimination.
>
> Suppose a business prohibits covering any part of one's head, so some
> Muslim women, Jewish men, and Sikh men, who consider certain head wear
> to be mandated by their religion, cannot work there. It's the same rule
> for everyone, so no discrimination.
>
> One can have a rule that is exactly the same for everyone, but has
> disproportionate effect on unfavored sub-populations. Are such rules
> ever discriminatory?

A related headline recently came up in the journalism field:

https://www.huffingtonpost.com.au/entry/employers-disability-discrimination-job-listings_l_5d003523e4b011df123c640a

I'm not suggesting this situation is akin to an ADA violation, but it's
food for thought, certainly.

Re: [DISCUSS] Outreachy framework proposal

[Joan Touzet]

Hi Naomi,

Sorry for the top post. This is good work! I'm glad you and Gris have a 
framework built around this, and I think it's going in all the right 
directions. You have my support!


-Joan

On 2019-06-24 10:45 a.m., Naomi Slater wrote:

I was lucky enough to catch up with Gris last week in Berlin for dinner. I
shared some of my ideas about I think we should work with Outreachy. as it
happens, it matches up quite well with what she already had in mind. and we
realized that elaborating on this stuff will hopefully do a better job of
explaining how this benefits the foundation

here's a rough sketch of what I am proposing:


- getting Outreachy interns working on our projects isn't the end goal.
we shouldn't be thinking of this as a way to improve our demographics one
intern at a time

our primary objective, as a committee, is to improve the foundation by
making our communities more welcoming, safe, inclusive, fair, easy to
contribute to, and so on. to that end, we need to understand the
experiences that people from under-represented groups have while trying to
contribute

- Outreachy presents a fantastic opportunity to work with and learn from
people as they go through that process

from the D&I committee's perspective, the purpose of each internship
should be to gather as much information as possible about the intern's
journey. and that information should focus on areas that relate to our
primary objective

- mentors are responsible for gathering this information, and reporting
back to the D&I committee regularly. in particular, we should look at
creating something like what Google calls friction logs. (thanks to Gris
for explaining this to me!)


https://devrel.net/developer-experience/an-introduction-to-friction-logging

a friction log is a form of user research, and this will complement the
other research we're planning

the difference here is that the information we gather through Outreachy
will be coming from people who are directly trying to contribute to the
ASF. whereas, the other research we are planning will focus on surveying
people who have not contributed

combined, this will give us a better picture of the overall "funnel"
(i.e., the stages of someone's awareness of, and involvement with, the
foundation). something we discussed on the lists, early this year

now, some additional details about how I propose we structure the program:

- mentors will have two primary responsibilities:


1. working with the intern, per Outreachy's own framework
   2. reporting back to the D&I committee, per a D&I mentorship
   framework that we will develop


- each mentorship requires a steward from the D&I committee. that
steward is responsible for working with the mentor to ensure they follow
the D&I mentorship framework

- the primary deliverable for each mentorship is a report (or set of
reports) to the D&I committee. reports are standardized as a part of the
D&I mentorship framework and will include friction logging and other
information pertinent to our primary objective. we will improve this
framework over time. (and indeed, we may be able to adapt it for other
sorts of internships)

- the D&I committee will then:
   1. handle all reports, synthesize them and attempt to draw conclusions
   2. develop recommendations based on those conclusions
   3. publish findings on our website or blog
   4. socialize those findings within the foundation

   - it will be up to the individual projects within the foundation to
decide how to make use of findings we publish. we will encourage people to
use disc...@diversity.apache.org (analogous to users@) as a support
forum for working with the information we publish


hopefully, with a structure like this in place, the Outreachy proposal
starts to address some of the outstanding concerns that people have

and I am hoping that we can develop this proposal into something more
concrete

thanks!

Re: can't get couchdb installed (on a fresh 18.04 ubuntu)

[Joan Touzet]

Hi Rene,

This isn't our problem, but it *is* an HPLIP problem.

https://askubuntu.com/questions/1056780/cant-upgrade-update-ubuntu-18-04-as-apt-dpkg-error-is-showing-up

Uninstall HPLIP from the .deb, then finish your upgrade, then reinstall 
HPLIP from .deb or source package.


-Joan

On 2019-06-24 4:55 a.m., Rene Veerman wrote:

i followed https://linuxize.com/post/how-to-install-couchdb-on-ubuntu-18-04/


but ended up with :

root@crow:~# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
   libargon2-0 libcryptsetup12 libdevmapper1.02.1 libidn11 libip4tc0
libjson-c3
   libkmod2 systemd
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
16 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Processing triggers for mime-support (3.60ubuntu1) ...
Setting up python3 (3.6.7-1~18.04) ...
running python rtupdate hooks for python3.6...
dpkg-query: package 'hplip-data' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Traceback (most recent call last):
   File "/usr/bin/py3clean", line 210, in 
 main()
   File "/usr/bin/py3clean", line 196, in main
 pfiles = set(dpf.from_package(options.package))
   File "/usr/share/python3/debpython/files.py", line 53, in from_package
 raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of hplip-data
error running python rtupdate hook hplip-data
dpkg-query: package 'ibus-hangul' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Traceback (most recent call last):
   File "/usr/bin/py3clean", line 210, in 
 main()
   File "/usr/bin/py3clean", line 196, in main
 pfiles = set(dpf.from_package(options.package))
   File "/usr/share/python3/debpython/files.py", line 53, in from_package
 raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of ibus-hangul
error running python rtupdate hook ibus-hangul
dpkg-query: package 'ibus-libpinyin' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Traceback (most recent call last):
   File "/usr/bin/py3clean", line 210, in 
 main()
   File "/usr/bin/py3clean", line 196, in main
 pfiles = set(dpf.from_package(options.package))
   File "/usr/share/python3/debpython/files.py", line 53, in from_package
 raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of ibus-libpinyin
error running python rtupdate hook ibus-libpinyin
dpkg-query: package 'ibus-table' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Traceback (most recent call last):
   File "/usr/bin/py3clean", line 210, in 
 main()
   File "/usr/bin/py3clean", line 196, in main
 pfiles = set(dpf.from_package(options.package))
   File "/usr/share/python3/debpython/files.py", line 53, in from_package
 raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of ibus-table
error running python rtupdate hook ibus-table
dpkg-query: package 'ibus' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Traceback (most recent call last):
   File "/usr/bin/py3clean", line 210, in 
 main()
   File "/usr/bin/py3clean", line 196, in main
 pfiles = set(dpf.from_package(options.package))
   File "/usr/share/python3/debpython/files.py", line 53, in from_package
 raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of ibus
error running python rtupdate hook ibus
dpkg-query: package 'python3-uno' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Traceback (most recent call last):
   File "/usr/bin/py3clean", line 210, in 
 main()
   File "/usr/bin/py3clean", line 196, in main
 pfiles = set(dpf.from_package(options.package))
   File "/usr/share/python3/debpython/files.py", line 53, in from_package
 raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of python3-uno
error running python rtupdate hook python3-uno
dpkg-query: package 'rhythmbox-plugin-alternative-toolbar' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
Traceback (most recent call last):
   File "/usr/bin/py3clean", line 210, in

Re: Why does the ASF not pay for development?

[Joan Touzet]

On 2019-06-24 11:32 a.m., Myrle Krantz wrote:

On Thu, Jun 20, 2019 at 1:05 PM Sam Ruby  wrote:


Also: if you can find some way to capture the "we can't fund
development of Whimsy because it is a  project" and "we shouldn't seek
to have an intern for Whimsy because it is not a real project", that
would be great!



  I think the wonderful thing about Whimsy is that it's kind of both.  It's
a community-driven project, which collects requirements from the needs of
the board.  It's probably too small for health (but isn't alone in that).
And despite the lack of funding, it's already driven by ASF-internal
requirements unlike the vast majority of our projects.  While we try to
maintain our neutrality with respect to the vast majority of software
development efforts hosted here, the ASF cannot credibly be called
*neutral* when it comes to Whimsy.  This probably contributes to
difficulties in growing that community.  But because it serves other
projects, it also means that anyone who works on Whimsy, has a greater
chance of coming into contact with many of our other projects, and the
people and communities who drive them.

I really hope that Whimsy remains on our shortlist of projects for an
Outreachy intern.


Sure, we can continue look for interns to deal with internal-facing 
projects, even Whimsy, but...look at the previously funded projects. How 
many of them are similar to Whimsy? For instance:


  https://www.outreachy.org/apply/rounds/2017-december-march/

The closest I see are some of Debian's and the Fedora Hubs project. But 
note that, for 2 open spots, Debian offered *9* opportunities. One 
cohort, the two selected interns both went into work on Debian's 
Continuous Integration - a clearly transferable skill, and an area where 
the ASF, incidentally, could really use some support. ;) Fedora's two 
interns worked on forking Happiness Packets[1], which again is something 
the ASF might want to consider - who of us wouldn't like to get one of 
these in their inbox?


So I guess where I'm ending up is the old improv saw, "Yes, and." Whimsy 
is just one potential project, but we should be thinking bigger. Much 
bigger, as you've said in your other email, than just Outreachy and Whimsy.


-Joan "Yes, and..." Touzet

[1]: https://www.happinesspackets.io/

Re: A way forward for CouchDB

[Joan Touzet]

Hi Chintan,

On 2019-06-21 7:21, Chintan Mishra wrote:
> Dear team,
> 
> I noticed this message on the Slack workspace by the user `@jan`
> 
> https://couchdb.slack.com/archives/C49LEE7NW/p1560856033217500
> 
> Quoting the message in the link:
> 
>    this would require very little erlang and we can help with that
>    part, what this project would need is someone who comes up with a
>    compelling technical vision that goes beyond “works for me / solves
>    my problems” and who is committed to maintain this going forward,
>    find a team that helps, etc.
> 
> After reading this, I realized there are a few things that we(CouchDB's
> team and Rebhu Computing's team) can do to help the CouchDB project
> right now. Here is a small list of those things:
> 
> 1. *Organize a competition*for getting people to know about CouchDB.
> 2. *Make CouchDB more visible*. Unlike most other popular databases the
>    online presence of CouchDB is not huge. Slack communication is not
>    search indexed which makes it difficult to get new people to see all
>    the things that are happening in the CouchDB world.
> 3. A *way forward for CouchDB is focusing on what it is best*at viz.,
>    being a database for _*C*__luster __*O*__f __*U*__nreliable
>    __*C*__ommodity __*H*__ardware_. Being deploy-able at edge devices.
>    Focusing on this will invite people building for IoTs towards
>    CouchDB. And this will drive a whole new set of users/customers
>    towards CouchDB and IBM's Cloudant project. We already use
>    Cloudant's sync-android and CDTDatastore in our startup's(Rebhu
>    Computing) product.
> 
> Here are someways we, Rebhu Computing, can help right away:
> 
> 1. We(Rebhu Computing) can organize a competition in India(Asia) where
>    people build things using CouchDB. This can have *a theme to
>    increase the number of participants*. And a jury can select the top
>    3 projects. The *winners get a T-Shirt* with CouchDB and startup's
>    branding. And their project will be hosted by us(Rebhu Computing)
>    for a year.

I'm +0 on the competition. I'm personally not a huge fan of competitive
activities, being more of a collaborative sort, but I recognize this
activity may make sense in your part of the world more than in mine.

As the Apache Software Foundation is a non-profit, it cannot be seen
that the Foundation has sponsored your *company* or your hosting service
- there are strict rules and regulations around this.

Quoting our policy: "Nothing in this ASF policy statement shall be
interpreted to allow any third party to claim any association with the
Apache Software Foundation or any of its projects or to imply any
approval or support by ASF for any third party products or services."

Our Third Party Event Branding policy is here:

https://www.apache.org/foundation/marks/events

Any CouchDB branding will have to be approved by the PMC and possibly
the Apache Software Foundation. Further, Apache CouchDB is a trademark
that the Foundation will defend vigorously.

> 2. Migrate to Spectrum chat  and *make all of
>    the CouchDB conversation search indexed*. No other DB community is
>    actively doing this and it will improve CouchDB's ranking on
>    DB-Engines website
>    . I have
>    personally wanted to do this for so long that I had already created
>    a CouchDB group on Spectrum almost a year ago.

No, thank you.

The ASF has traditionally used IRC, and more recently Slack, for real
time chatting. We are happy to stay with the tools supported by and used
by the Foundation.

Perhaps someone would consider setting up a Slack-to-IRC gateway for the
Freenode #couchdb channel (which we lost when Slack discontinued the
gateway). Plenty of logging solutions exist for IRC. This would prevent
us having to uproot the community and use a new client.

> 3. I would love to know the *viewpoint of the whole team* about the
>    suggested way forward for CouchDB.

That's my opinion. :)

-Joan

Re: quick question about structures

[Joan Touzet]

On 2019-06-19 4:11 p.m., Jim Jagielski wrote:

I would even go further: if someone on the D&I cmmt (or elsewhere in the ASF) 
wished to contact their employer directly and see if they would sponsor Outreachy 
(directly) to work on an ASF project (or projects) then again, I would not see any 
problem w/ that. How could I? Similar things have happened since Day 1.

Since we would not be the middle-man, so to speak, we would not be paying for 
development; nor would we need to figure out some 'loophole' or 'work-around' 
around that principle; nor would this effort in any way chip away at that 
principle nor create some precedent 'around' it.
This is all moot anyway. The Board has denied the funding for Outreachy. 
Let's drop the topic, nothing good will come from it.


The committee will continue to work on the secondary funding option, 
which has been proposed in parallel by about 20 people. ;)


What I'd like (as a member of the committee) is for people involved in 
ASF projects who are on this list to start surveying to find out:


* would you like an Outreachy intern?
* do you have the people/hours to mentor effectively (6h/week)?
* during which of the upcoming 2x Outreachy cohort periods would you
  be able to participate (August 2019, late January 2020?

The more we know about which projects might be interested, the clearer 
our mission re: external fundraising and sponsorship will be.


-Joan "moving on" Touzet

Re: Results of the 2016 diversity survey at Apache

[Joan Touzet]

On 2019-06-18 3:03 p.m., Daniel Shahaf wrote:

Myrle Krantz wrote on Tue, 18 Jun 2019 16:30 +00:00:

The survey provides an incomplete picture and the data is imperfect. In
addition, we need to find ways to think about diversity that do justice
to the international nature of our foundation and our projects.


I've mentioned it on private lists but I'll repeat it here: being an
email-centered culture, our social bugs are probably different than
those of traditional corporations.  For example, it would be practically
impossible for us to discriminate against bearded people even if we
_wanted_ to, while a PMC could easily be exclusive towards people who
don't have GitHub accounts.


Except that GitHub accounts have pictures, and many participants have 
their own websites, blogs, Twitter/FB/LinkedIn accounts, etc.


We don't live in a world anymore where the *only* interaction with and 
understanding of an individual's identity is their From: line. Heck, 
many mail clients proactively go and fetch this data now in a sidebar; 
our own PonyMail list archive displays Gravatars by default.

But this survey is at least an excellent argument for seeking more
data and a deeper understanding.


I would suggest to seek case studies: accounts by specific people who
were/are excluded.


Unless I'm mistaken, this is effectively asking to prove a negative.

-Joan

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: One-on-one mentoring

[Joan Touzet]

[cw: mention of theoretical sexual assault]

Hi Daniel,

On 2019-06-18 3:09 p.m., Daniel Shahaf wrote:

Random idea: Can we do something like the "CoC contacts" but for people
who feel uncomfortable joining a community?  For example, some sort of
way to pair people with one-on-one mentors?


I believe Shane is working on a new mentorship website/framework that 
could meet this need. I'd like to ask him to chime in on any specific 
considerations he has re: diversity and inclusion within that new system.


Once that system is ready to go, it'd be a matter of promoting it, 
alongside its support for D&I-specific topics.



Or, to scale better, set up a *privately-archived* how-can-i-h...@apache.org
mailing list, where people who want to join but are reluctant to can
contact us?

>

http://community.apache.org/mentorprogrammeapplication.html doesn't
quite fit the bill, IMO, for two reasons: it uses a public mailing list
and requires proposing a weeks-sized "project", whereas new contributors
typically get started with fixing typos or minor bugs.
]]]


I'm nervous about this, because often questions re: personally important 
D&I topics are things that you might not want to perennially have 
available to all future members of that group.


Example: If I were someone who'd been sexually assaulted at a (non-ASF) 
tech conference, and wanted to ask someone @ the ASF about policies and 
procedures in place to prevent something similar happening to me within 
Apache ProjectX, or how it might be handled if it occurred, I wouldn't 
want that archived at all. I definitely wouldn't want it archived if my 
assaulter might someday be in a position to read it, either.


I think that, once the Mentoring system above is up and running, and 
there's names of friendly people willing to help newbies get involved in 
the ASF, some of whom self-identify with groups that match those of 
applicants, it'd be a better option than a list. But it does come with 
some specific needs, such as: mentors actually responding to applicants, 
support materials re: what does D&I mean at the ASF, how we define and 
enforce our CoC, etc.


If you're talking about something that isn't specific to a D&I 
initiative, but just community development, ComDev's mailing list might 
be more appropriate.


-Joan "yay friendly web interfaces" Touzet

[jira] [Commented] (WHIMSY-260) Cannot see prior comments on PMR reports

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866080#comment-16866080
 ] 

Joan Touzet commented on WHIMSY-260:


FYI [~rubys] and others I am still affected by this and haven't been able to 
find a suitable workaround - which in turn affects my Board responsibilities & 
workflow. I expect it is related to ad blocking plugins or browser settings on 
my end, but these are non-negotiable on my part. It's still failing in both 
Chromium and Firefox.

> Cannot see prior comments on PMR reports
> 
>
> Key: WHIMSY-260
> URL: https://issues.apache.org/jira/browse/WHIMSY-260
> Project: Whimsy
>  Issue Type: Bug
>  Components: BoardAgenda
>Reporter: Joan Touzet
>Priority: Critical
> Attachments: Archive 19-05-10 16-24-02.har, MWSnap 2019-05-10, 
> 15_48_56.png
>
>
> When I browse to a given report, such as:
>    [https://whimsy.apache.org/board/agenda/2019-05-15/Lens]
> I cannot see any comments from prior meetings. I have tried the following 
> browser combinations with no luck:
>  * Firefox ESR, Linux (60.6.2)
>  * Firefox Stable, Win64 (66.0.x)
>  * Chromium, Win64 (66.0.something)
> I have tried this both with a "wide" browser (so the comments section is to 
> the right in 2-column format) and a "narrow" browser (all in a single column) 
> to no effect.
> Other board members tell me that they see these comments below the section 
> for any comments being filed for the current month.
> Screenshot attached.
> Am I missing permissions of some sort?
> This is making it hard to review reports, since I am lacking a significant 
> amount of context from prior board members' comments.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: (Input needed by 6/13 EOD) Decision on budget request for an Outreachy pilot

[Joan Touzet]

Hello everyone, I'm in transit and I'm officially out until Monday, but 
wanted to respect Gris's request for feedback by the end of today.


(FYI: My email is being authored offline, and I have no emails newer 
than ~06-12 18:00 EDT. I'm sending to dev@, and have set Reply-To to 
dev@, because it's important we discuss this as much as possible in public.)


CC'ing Greg Stein and David Nalley for Infra questions.


# Summary

  * I support the initiative overall.
  * I support the Outreachy budget item (Option 1) as seed money, but
  * I think external funding for interns should be the goal (Option 2).
  * Pick the right *tech focused*, externally useful project. I propose
PonyMail.
  * This budget line-item should be extended to cover any paid Infra
staff's mentoring effort (see below for details, estimate 5h/week)
because Infra won't have budgeted for this additional load we'd be
asking of them.
  * My other ASF responsibilities mean I probably cannot be Outreachy's
main champion for FY2020, sorry, but happy to help as much as I can.
  * Sorry for the length of this email. I tried hard to make it shorter :(


# On Outreachy

As I understand it, Outreachy's focus is getting individuals in 
under-represented groups who are economically unable to sustain 
themselves both the funding and the support they need so they can 
successfully volunteer their time in open source development, with a 
core focus on *coding*.


One of Outreachy's most notable achievements, which took many years to 
achieve, was working out how to help get inexperienced devs successful 
in contributing to the Linux kernel. They're really successful in this! 
They built a lot of supports around that process that thankfully the ASF 
shouldn't need - in fact, they require applicants to prove their 
suitability through a kind of gauntlet - but this is the type of "big 
profile" engagement that we should be aiming for when we propose to them.


Remember: just because we want to work with Outreachy doesn't mean 
they'll agree to work with us, if it doesn't look like a good fit. We 
get interviewed, too. :)



# So what project or projects make sense?

I also like Niall's suggestion of 2x interns in FY2020, one in each of 
the two cohorts.


We need a crisp, technical-first opportunity. Since D&I hasn't started 
to liaise with ASF Project PMCs yet (beyond those represented these 
lists), I agree the first FY20 cohort (August 2019) would be a trial 
run, using a central ASF-wide project. D&I has a clearer mandate here, 
and it'll be easier to liaise with central groups. That leaves us 
sufficient time to get 1 or more non-central projects engaged for the 
Late January 2020 cohort.


We have a lot of "cobbler's children have no shoes" projects at the ASF, 
and I'd love more bodies on them (especially anything that makes PMC's 
lives easier when interfacing with Infra, the Board, or announce@a.o), 
but Outreachy is about putting the needs of the *intern* first, *not* 
our needs. They'd probably reject work on Whimsy on these grounds, in my 
opinion.


We need to consider that this individual likely won't be an ASF 
contributor or committer yet, either, so a project that has strong value 
outside the ASF as well would be best.


Also, while there is room for documentation projects, website redesigns, 
training materials and so on, I'd argue that these aren't the best 
opportunities for an Outreachy intern. All too often it's precisely this 
"work no one else wants to do" that falls to under-represented 
individuals. It'll look especially bad if our first attempt at a 
diversity initiative comes off as throwing undesirable work "over the 
wall" to a minority intern. (It'd be even worse if it also looked like 
we were asking them to do diversity-focused work...no one's proposed 
this, just saying.)


Things that touch the most people possible, AND have external-to-Apache 
users would be the best opportunities. I think PonyMail might be the 
best central project here. Can anyone think of others?



# On Mentoring

Reminder: if we're picking a project primarily supported and run by 
Infra staff like PonyMail, many of these are ASF-paid people. Their 
hours are already allocated and tracked by Infra management for the huge 
number of things we ask of them. (Read as: they're already overworked 
and underpaid.)


Assuming at least the first intern would be working on e.g. PonyMail, 
let's budget for an additional 5h/week for Infra staff to cover the 
expected mentoring duties. This shows respect to Infra for their time 
and effort, even if this just ends up looking on the books like 
Department A paying Department B.


This whole proposal is still contingent on Infra agreeing to work 
together on this. No one wants to be "volun-told." That, too, would look 
really bad (on D&I, not the ASF at large).


So, Greg/David (on CC): How does this sound to you? If positive (even if 
PonyMail isn't exactly the right project), is this 5h/week a n

Re: committers: r91090 - /committers/board/committee-info.txt

[Joan Touzet]

Sorry about that. It was Sally Khudari who recommended these changes be 
made because of the missing VP role in plenty of places. I agree that 
the text file needs work.


Tom still needs to be removed from the file if you didn't do that.

Also this seems out of step with the website; is there any way these 
files could be better integrated rather than a warning in the file that 
you have to edit both places at once?


-Joan

On 2019-06-11 7:06 p.m., sebb wrote:

I've reverted the commit as it broke lots of Whimsy output

On Tue, 11 Jun 2019 at 17:47, sebb  wrote:


On Tue, 11 Jun 2019 at 16:22,  wrote:


Author: wohali
Date: Tue Jun 11 15:22:45 2019
New Revision: 91090

Log:
Remove Tom from Sponsor Relations (since 2009.1.1), add VP titles



Please don't change the file syntax; it messes with various scripts
that parse the file (e.g. Whimsy)
The changes need to be reverted please.

[Also please use separate commits for independent changes.]


Modified:
 committers/board/committee-info.txt

Modified: committers/board/committee-info.txt
==
--- committers/board/committee-info.txt [utf-8] (original)
+++ committers/board/committee-info.txt [utf-8] Tue Jun 11 15:22:45 2019
@@ -72,7 +72,7 @@ automatically updates the LDAP group mem


  The Apache Software Foundation has the following Project Management
-Committees (PMCs):
+Committees (PMCs), with these named Vice Presidents:

  NAMECHAIR
  --  ---
@@ -281,26 +281,26 @@ Committees (PMCs):
  ZooKeeper   Flavio Junqueira 


-The ASF also has the following Board Committees:
+The ASF also has the following Board Committees, with the following named:

  NAME  CHAIR
  -----
-Legal Affairs Roman Shaposhnik 
-Security Team Mark J. Cox 
-Data Privacy  John Kinsella 
+V.P., Legal Affairs   Roman Shaposhnik 
+V.P., Security Team   Mark J. Cox 
+V.P., Data PrivacyJohn Kinsella 


  The ASF also has the following President's Committees:

-NAME  CHAIR
------
-Brand Management  Mark Thomas 
-Conferences   Rich Bowen 
-Diversity and Inclusion   Griselda Cuevas 
-Finance   Tom Pappas 
-Fundraising   Daniel Ruggeri 
-Marketing and Publicity   Sally Khudairi 
-Travel Assistance Gavin McDonald 
+NAMECHAIR
+--  ---
+V.P., Brand Management  Mark Thomas 
+V.P., Conferences   Rich Bowen 
+V.P., Diversity and Inclusion   Griselda Cuevas 
+V.P., Finance   Tom Pappas 
+V.P., Fundraising   Daniel Ruggeri 
+V.P., Marketing and Publicity   Sally Khudairi 
+V.P., Travel Assistance Gavin McDonald 


  The ASF also has the following Executive Officers:
@@ -321,11 +321,10 @@ The ASF also has the following additiona

  OfficeOfficer
  -----
-W3C Relations Andy Seaborne 
-InfrastructureDavid Nalley 
+V.P., W3C Relations   Andy Seaborne 
+V.P., Infrastructure  David Nalley 
  Infrastructure Administrator  Greg Stein 
-Sponsor Relations Sally Khudairi 
-Sponsor Relations Tom Pappas 
+V.P., Sponsor Relations   Sally Khudairi 


  Note that per the bylaws section 6.3, an officer of the corporation

Re: Fwd: [PROPOSAL] send automated emails to dev@diversity

[Joan Touzet]

Hi Trevor,

On 2019-05-29 6:55 p.m., Trevor Grant wrote:

If the repo is only website code, then you can do it with git pages.


ASF Infra has special code that extends beyond the functionality of 
GitHub Pages. We'll work with them to have the site published.


I was referring to this code when I talked about using the special 
"asf-site" branch.


You can see this here:

https://github.com/apache/couchdb-www



However,  back to original proposal of "email us changes",

I might recommend another mailing list like commits@d.a.o for the automated
stuff (which I also think is sometimes a standard practice) bc depending
how many commits you're getting, that can get real spammy real fast.


I agree, though hopefully it's not changing that often...and we're still 
a small group. Let's deal with splitting the lists when the volume 
becomes too high.


-Joan

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Fwd: [PROPOSAL] send automated emails to dev@diversity

[Joan Touzet]

Hi Trevor,

On 2019-05-29 6:55 p.m., Trevor Grant wrote:

If the repo is only website code, then you can do it with git pages.


ASF Infra has special code that extends beyond the functionality of 
GitHub Pages. We'll work with them to have the site published.


I was referring to this code when I talked about using the special 
"asf-site" branch.


You can see this here:

https://github.com/apache/couchdb-www



However,  back to original proposal of "email us changes",

I might recommend another mailing list like commits@d.a.o for the automated
stuff (which I also think is sometimes a standard practice) bc depending
how many commits you're getting, that can get real spammy real fast.


I agree, though hopefully it's not changing that often...and we're still 
a small group. Let's deal with splitting the lists when the volume 
becomes too high.


-Joan

Re: GSuite Team Drive

[Joan Touzet]

Oh HI Mark,

I should have an apache.org gsuite account. Can you add me access? Thanks.

-Joan

On 2019-05-29 6:18, Mark Thomas wrote:
> On 29/05/2019 11:11, Naomi Slater wrote:
>> I'd like access, please. what info do you need?
> 
> I'll get you set up. Expect a few emails from Google as I create you
> account.
> 
> Mark
> 
> 
>>
>> On Wed, 29 May 2019 at 11:18, Myrle Krantz  wrote:
>>
>>> Just FYI:
>>>
>>> Kevin has created an Apache GSuite Team drive for D&I.
>>>
>>> Currently there are three team members with "manager" access: Gris, Kevin,
>>> and me.  Feel free to request access for yourself or anyone else.
>>>
>>> It doesn't contain anything yet, but many of us like working in google
>>> docs, so here's a place to do it on Apache Infra.
>>>
>>> Best,
>>> Myrle
>>>
>>
> 
> 
> -
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: [PROPOSAL] send automated emails to dev@diversity

[Joan Touzet]

Also +1 for Git, and if it's like the project in which we're involved,
an asf-site branch can def. be used to autopublish a website.

-Joan

On 2019-05-29 8:43, Myrle Krantz wrote:
> On Wed, May 29, 2019 at 1:46 PM Naomi Slater  wrote:
> 
>> Git imo. so we can work on GitHub (assuming this is in fact possible for
>> the website)
>>
> 
> +1 Git.  I use svn when I have to, but I'm not super comfortable with it
> yet.
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

[jira] [Created] (WHIMSY-266) Special support for Incubator

[Joan Touzet (JIRA)]

Joan Touzet created WHIMSY-266:
--

 Summary: Special support for Incubator
 Key: WHIMSY-266
 URL: https://issues.apache.org/jira/browse/WHIMSY-266
 Project: Whimsy
  Issue Type: New Feature
  Components: BoardAgenda, Website
Reporter: Joan Touzet


Reviewing the Incubator status is challenging for me, and I would guess for 
other Directors. Some improvements would be lovely.

If I had 3 wishes:
 # Each podling's report would appear on a separate page. So would the overall 
Incubator status.
 # I could individually leave comments on each podling, then overall 
approve/comment/flag the entire report when I'm done.
 # Podling reports could use better markup, dependent on the resolution of 
WHIMSY-265.

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: D&I 2020 budget Request

[Joan Touzet]

+1 to both of these, with the addition that we consider a consultancy
that could support us in authoring a statistically and sociologically
valid survey as well. This is critically important as a foundational
step, let's get some experts in here. (Entire PhDs get written on survey
methodology.)

-Joan "yay, Outreachy!" Touzet

On 2019-05-23 4:46, Naomi Slater wrote:
> two things immediately come to mind:
> 
> 1. money for hiring consultants (as was previously discussed on ComDev)
> 
> 2. money for funding/sponsoring diversity internships/scholarships
> (Outreachy, etc)
> 
> On Thu, 23 May 2019 at 00:53, Griselda Cuevas  wrote:
> 
>> Hi folks -
>>
>> 2020 budget planning is upon us, and I'd like us to brainstorm ideas on
>> what could we request budget for.
>>
>> Let's keep this discussion going as a brainstorm, avoid critizicing other
>> ideas but please feel free to suggest alternatives to things you don't
>> agree with.
>>
>> I will keep the thread open until Monday to finalize our formal budget
>> request.
>>
>> Thanks!
>>
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Use ExUnit to write unit tests.

[Joan Touzet]

On 2019-05-23 11:15, Paul Davis wrote:
> I'm pretty happy with the ExUnit we've got going for the HTTP
> interface and would be an enthusiastic +1 on starting to use it for
> internals as well.

Wait, where's the full ExUnit implementation for the HTTP interface? Is
that Ilya's PR, or something that Cloudant runs internally?

If you mean the slow conversion of the JS tests over to Elixir, I wasn't
aware that these were implemented in ExUnit already. Learn something new
every day!

> The only thing I'd say is that the adapter concept while interesting
> doesn't feel like it would be that interesting for our particular
> situation. I could see it being useful for the 5984/5986 distinction
> since its the same code underneath and we'd only be munging a few
> differences for testing. However, as Garren points out 5986 is going
> to disappear one way or another so long term not a huge deal.

+1, the intent was to deprecate 5986 for CouchDB 3.0, and obviously it's
gone for 4.0.

-Joan

Re: D&I 2020 budget Request

[Joan Touzet]

On 2019-05-23 8:19, Awasum Yannick wrote:> 3.) Money to sponsor an
Apache Con in Africa(even a road show) or some
> other under represented location. Has there been an Apache Con in Asia or
> developing parts of the world?
> I mostly hear about North America and Europe.

With my ASF Director hat on, PLEASE PLEASE PLEASE do not initiate work
on running any medium or large sized conference in any territory without
first discussing your idea with Rich Bowen and the Conferences
committee. These are massive undertakings and require team planning and
careful consideration, not just one person's heroic efforts. The ASF
only has so much bandwidth to run these in any given year.

Small events ("meetup" sized) already have a new budget line-item that
I'm working on, and there will be a nice and easy way to run these with
minimal involvement necessary from the ASF side.


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Use ExUnit to write unit tests.

[Joan Touzet]

Hi Ilya, thanks for starting this thread. Comments inline.

On 2019-05-22 14:42, Ilya Khlopotov wrote:
> The eunit testing framework is very hard to maintain. In particular, it has 
> the following problems:
> - the process structure is designed in such a way that failure in setup or 
> teardown of one test affects the execution environment of subsequent tests. 
> Which makes it really hard to locate the place where the problem is coming 
> from.

I've personally experienced this a lot when reviewing failed logfiles,
trying to find the *first* failure where things go wrong. It's a huge
problem.

> - inline test in the same module as the functions it tests might be skipped
> - incorrect usage of ?assert vs ?_assert is not detectable since it makes 
> tests pass 
> - there is a weird (and hard to debug) interaction when used in combination 
> with meck 
>- https://github.com/eproxus/meck/issues/133#issuecomment-113189678
>- https://github.com/eproxus/meck/issues/61
>- meck:unload() must be used instead of meck:unload(Module)

Eep! I wasn't aware of this one. That's ugly.

> - teardown is not always run, which affects all subsequent tests

Have first-hand experienced this one too.

> - grouping of tests is tricky
> - it is hard to group tests so individual tests have meaningful descriptions
> 
> We believe that with ExUnit we wouldn't have these problems:

Who's "we"?

> - on_exit function is reliable in ExUnit
> - it is easy to group tests using `describe` directive
> - code-generation is trivial, which makes it is possible to generate tests 
> from formal spec (if/when we have one)

Can you address the timeout question w.r.t. EUnit that I raised
elsewhere for cross-platform compatibility testing? I know that
Peng ran into the same issues I did here and was looking into extending
timeouts.

Many of our tests suffer from failures where CI resources are slow and
simply fail due to taking longer than expected. Does ExUnit have any
additional support here?

A suggestion was made (by Jay Doane, I believe, on IRC) that perhaps we
simply remove all timeout==failure logic (somehow?) and consider a
timeout a hung test run, which would eventually fail the entire suite.
This would ultimately lead to better deterministic testing, but we'd
probably uncover quite a few bugs in the process (esp. against CouchDB
<= 4.0).

> 
> Here are a few examples:
> 
> # Test adapters to test different interfaces using same test suite

This is neat. I'd like someone else to comment whether this the approach
you define will handle the polymorphic interfaces gracefully, or if the
effort to parametrise/DRY out the tests will be more difficulty than
simply maintaining 4 sets of tests.


> # Using same test suite to compare new implementation of the same interface 
> with the old one
> 
> Imagine that we are doing a major rewrite of a module which would implement 
> the same interface.

*tries to imagine such a 'hypothetical' rewrite* :)

> How do we compare both implementations return the same results for the same 
> input?
> It is easy in Elixir, here is a sketch:

Sounds interesting. I'd again like an analysis (from someone else) as to
how straightforward this would be to implement.

-Joan

Re: FAQ and paywall articles

[Joan Touzet]

On 2019-05-22 13:15, Patricia Shanahan wrote:> Do keep the ideas coming,
especially if you know something that works
> for social science but not computer science. I have done a lot of
> academic literature searches but only in computer science.

One option can be to look for conference talks given by the authors of
those papers. You can do the APA reference to the paper itself, then
maybe link to a video of the author speaking about it.

In general you already know all of the other tricks I tend to use: fair
use excerpts such as abstracts, looking at the author's website to see
if they have a pre-print or similar version available, hitting the
journal's website for the abstract/conclusion, Google Scholar, etc.

Sometimes emailing the author and asking for a copy works, which you can
also include as an mention in the FAQ if it worked for a particular
paper/topic. They may also be able to grant permission for a section to
be excerpted for our specific needs. (I've gotten this in the past for
chapters from a book, for instance.)

I've got a trove of articles I'll try and dig through soon, maybe on my
next flight, that could be useful - most of them focused on distributed
cognition, communities of practice, and distance-working, all of which I
think are relevant to running a sustainable community (even if not
specific to D&I topics.)

-Joan "moar social science papers!" Touzet


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: FAQ and paywall articles

[Joan Touzet]

On 2019-05-22 10:37, Naomi Slater wrote:
> On Wed, 22 May 2019 at 16:19, Justin Mclean 
> wrote:
> 
> People often in email list use terms, while possible known, often have a
>> very different meanings outside of the US. A large number of US corporate,
>> sporting or gambling idioms, would be lost on most people outside the US
>>
> 
> I was hoping to include things like this under "dialect". it's not just
> regional idioms, terms, etc. but cultural ones too. words like "grok",
> "bikeshedding", "strawman", etc, can all signal in-group status

One that has really caused me problems recently is "tabled," in the
context of an official meeting or in parliamentary procedure.

In most of the world, saying "The proposal has been tabled" means that a
new proposal is up for active discussion and decision-making in front of
a group of people.

In the US, it has *exactly the reverse meaning*; "The proposal was then
tabled" means any decision on the proposal has been deferred to a later
date, pending additional (off-line/mailing list) discussion.

https://en.wikipedia.org/wiki/Table_%28parliamentary_procedure%29

This infuriates me :D

-Joan "two sheds" Touzet


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: FAQ and education mailing list

[Joan Touzet]

And for clarity I was not accusing you of cookie licking :D Thank you
for taking the initiative with the wiki FAQ!

-Joan

On 2019-05-21 17:30, Patricia Shanahan wrote:
> In that connection, I want to make sure people understand I do not want
> to stop other people from editing the Resources or FAQ pages. I will
> publish often enough that I can easily merge any changes I've made since
> the last publish. I just wanted to get things started ASAP. Think of me
> as having cut a corner off the cookie using a clean knife, so that what
> remains on the tray is perfectly edible.
> 
> On 5/21/2019 10:27 AM, Joan Touzet wrote:
>> I'll admit I mostly link it because of this topic:
>>
>>    https://communitymgt.fandom.com/wiki/Cookie_Licking
>>
>> which is a real thing that kills communities quickly. Though, their
>> other anti-pattern pages are good, too.
>>
>> There's an amazing number of trackers on the web these days. I don't
>> think we should exclude access because of them, or warn about them
>> either. (That'd directly rule out most of the top 100 websites, I
>> believe...)
>>
>> If you're concerned about trackers (as I am), you'll already have
>> multiple browser plugins installed to block them. But I won't block it
>> if you want to put a warning on the wiki page - consider this a -0 on a
>> warning? :)
>>
>> -Joan "what was life like before ASF-style numerical voting?" Touzet
>>
>> On 2019-05-18 13:02, Patricia Shanahan wrote:
>>>
>>>
>>> On 2019/05/13 16:43:11, Joan Touzet  wrote:
>>> ...
>>>> * Some excellent resources are below, including a final article on why
>>>>    "If you don't teach me, how can I learn?" is a tried-and-true
>>>>    derailing technique and not an honest request for assistance. I'd
>>>>    think that these kinds of articles would be good as a "Resources"
>>>>    section, which I think is generally better than a FAQ since it can
>>>>    be too narrow, and thus be "game theoried"/"rule lawyered" around
>>>>    by the determined derailer.
>>> ...
>>>>    * https://communitymgt.fandom.com/wiki/Community_Management_Wiki
>>>
>>> According to the Ghostery Firefox plug-in, this page carries 11
>>> trackers. Do you feel strongly that it should be included in the
>>> Resources page?
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
>>> For additional commands, e-mail: diversity-h...@apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
>> For additional commands, e-mail: diversity-h...@apache.org
>>
> 
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com
> 
> 
> -
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

[jira] [Commented] (WHIMSY-265) Support rendering of Markdown and/or Asciidoc

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845227#comment-16845227
 ] 

Joan Touzet commented on WHIMSY-265:


Yes, officer/PMC submitted reports to either Whimsy or manually placed in SVN 
should IMO allow Markdown, Asciidoc, or both. IMO Markdown is a higher priority 
than Asciidoc.

And yes, +1 to the bonus.

I'm not in a place to even look at the code, sorry, or I'd offer to submit a 
patch/PR.

I hope the Whimsy team has enough [round 
tuits|https://en.wiktionary.org/wiki/round_tuit] to handle this request without 
my coding assistance. :)

> Support rendering of Markdown and/or Asciidoc
> -
>
> Key: WHIMSY-265
> URL: https://issues.apache.org/jira/browse/WHIMSY-265
> Project: Whimsy
>  Issue Type: New Feature
>  Components: BoardAgenda, Website
>Reporter: Joan Touzet
>Priority: Major
>
> This is a nice-to-have.
> Reports to the Board could be written in Markdown or Asciidoc. Optionally, 
> they may want to tag themselves as being in this format via a one-line 
> comment header or similar.
> Whimsy could then nicely format these reports if desired on the web 
> interface. Or not, they're very readable as text formats.
> At the very least, Whimsy needs to not choke on Markdown or Asciidoc in 
> submitted reports, which I believe it won't, but would be good to officially 
> hear it doesn't.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WHIMSY-265) Support rendering of Markdown and/or Asciidoc

[Joan Touzet (JIRA)]

Joan Touzet created WHIMSY-265:
--

 Summary: Support rendering of Markdown and/or Asciidoc
 Key: WHIMSY-265
 URL: https://issues.apache.org/jira/browse/WHIMSY-265
 Project: Whimsy
  Issue Type: New Feature
  Components: BoardAgenda, Website
Reporter: Joan Touzet


This is a nice-to-have.

Reports to the Board could be written in Markdown or Asciidoc. Optionally, they 
may want to tag themselves as being in this format via a one-line comment 
header or similar.

Whimsy could then nicely format these reports if desired on the web interface. 
Or not, they're very readable as text formats.

At the very least, Whimsy needs to not choke on Markdown or Asciidoc in 
submitted reports, which I believe it won't, but would be good to officially 
hear it doesn't.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] committee resources

[Joan Touzet]

+1 with Kenn's discuss@diversity. We are not developers, and I worry
that dev@diversity.a.o will make us seem too much like a software
development project.

-Joan "already too much software dev in my life" Touzet

On 2019-05-20 0:56, Kenneth Knowles wrote:
> On Sat, May 18, 2019 at 3:31 PM Griselda Cuevas 
> wrote:
> 
>> Hi folks,
>>
>> My vote is as follow:
>> - Mailing lists: +1 to Sam's proposal, i.e. dev@diversity,
>> private@diversity
>> & discuss@diversity with a redirecting alias for diversity@a.o
>>
> 
> +1 though I prefer discuss@diversity be the alias and diveristy@a.o be the
> primary. Either way is good.
> 
> Kenn
> 
> 
> 
> 
>> - Website: +1
>>
>> I'd suggest we put some thoughts on the page design to make it accesible
>> and easy to find info, so let's request the creation of the URL and kick
>> start a Jira Board to organice building the page. I'll pause this
>> discussion here to avoid noise.
>>
>>
>> On Fri, May 17, 2019, 4:42 PM Aizhamal Nurmamat kyzy
>>  wrote:
>>
>>> +1 on Sam's proposal.
>>>
>>> Thank you,
>>>
>>> *From: *Naomi Slater 
>>> *Date: *Fri, May 17, 2019 at 1:01 PM
>>> *To: * 
>>>
>>> I’m +1 on your counter proposal, Sam

 On Fri 17. May 2019 at 21:37, Sam Ruby  wrote:

> On Fri, May 17, 2019 at 9:20 AM Naomi Slater 
>>> wrote:
>>
>> in summary, I have three proposed actions:
>>
>> - create diversity-private@
>> - create diversity-discuss@ or diversity-dev@
>
> Counter proposal, consider:
>
> private@diversity
> dev@diversity
>
> And ask that diversity@ be renamed to discuss@diversity, with
> diversity@ being an alias for that list. The end result will be
> something like infra, which is not a PMC:
>
> https://lists.apache.org/list.html?us...@infra.apache.org
>
> Note the list of mailing lists(*), including a drop down for other
>>> lists.
>
>> - create https://diversity.apache.org/
>
> +1 to this.
>
> - Sam Ruby
>
> (*) In case anyone is wondering, devnull is not a real list, it is
> just there for infra testing purposes.
>
> -
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
>
>

>>>
>>
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: FAQ and education mailing list

[Joan Touzet]

I'll admit I mostly link it because of this topic:

  https://communitymgt.fandom.com/wiki/Cookie_Licking

which is a real thing that kills communities quickly. Though, their
other anti-pattern pages are good, too.

There's an amazing number of trackers on the web these days. I don't
think we should exclude access because of them, or warn about them
either. (That'd directly rule out most of the top 100 websites, I
believe...)

If you're concerned about trackers (as I am), you'll already have
multiple browser plugins installed to block them. But I won't block it
if you want to put a warning on the wiki page - consider this a -0 on a
warning? :)

-Joan "what was life like before ASF-style numerical voting?" Touzet

On 2019-05-18 13:02, Patricia Shanahan wrote:
> 
> 
> On 2019/05/13 16:43:11, Joan Touzet  wrote: 
> ...
>> * Some excellent resources are below, including a final article on why
>>   "If you don't teach me, how can I learn?" is a tried-and-true
>>   derailing technique and not an honest request for assistance. I'd
>>   think that these kinds of articles would be good as a "Resources"
>>   section, which I think is generally better than a FAQ since it can
>>   be too narrow, and thus be "game theoried"/"rule lawyered" around
>>   by the determined derailer.
> ...
>>   * https://communitymgt.fandom.com/wiki/Community_Management_Wiki
> 
> According to the Ghostery Firefox plug-in, this page carries 11 trackers. Do 
> you feel strongly that it should be included in the Resources page?
> 
> 
> -
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Recommendations for inclusive events

[Joan Touzet]

My presentation at ApacheCon 2018[1] includes a slide on just some of
the things that JSConf EU 2018 did to ensure accessibility and
inclusivity. Note especially the link to the Global Diversity CFP Day
event[2] which I think is gangbusters, and we should consider hosting
one of those at ApacheCon. They've expanded that this year with even
more[3].

-Joan "will keep linking it until I'm blue in the face" Touzet


[1]:
https://speakerdeck.com/wohali/building-and-sustaining-inclusive-communities?slide=15
[2]: https://www.globaldiversitycfpday.com/
[3]: https://2019.jsconf.eu/an-update/ and scroll to "In addition"

On 2019-05-17 9:37, Patricia Shanahan wrote:
> It is going on the "Resources" page anyway, but it might be good for
> people to think and write about how to hold inclusive Apache events.
> 
> On 5/17/2019 6:31 AM, Naomi Slater wrote:
>> this is great
>>
>> should this go on a wiki page or in a JIRA ticket or something? so we
>> don't
>> lose it. I'm presuming that potentially there's work/info here for us to
>> adapt/integrate
>>
>>
>>
>> On Fri, 17 May 2019 at 11:51, Bertrand Delacretaz
>> 
>> wrote:
>>
>>> Hi,
>>>
>>> FWIW I stumbled on https://github.com/hcorona/diversity-inclusion (via
>>> https://twitter.com/lsmith/status/1129308724827447296) and I quite
>>> like that set of suggestions - lots of good practical advice IMO.
>>>
>>> -Bertrand
>>>
>>> -
>>> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
>>> For additional commands, e-mail: diversity-h...@apache.org
>>>
>>>
>>
> 
> -
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

[jira] [Closed] (COUCHDB-3433) rename "bylaws" to "community guidelines"

[Joan Touzet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joan Touzet closed COUCHDB-3433.

Resolution: Fixed

> rename "bylaws" to "community guidelines"
> -
>
> Key: COUCHDB-3433
> URL: https://issues.apache.org/jira/browse/COUCHDB-3433
> Project: CouchDB
>  Issue Type: Task
>Reporter: Naomi Slater
>Priority: Major
>
> see here:
> [https://lists.apache.org/thread.html/e5a17e8263dbc8efdd7e20978d653f3ede6c5488c4970d545d340d7f@%3Cdiversity.apache.org%3E]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Need help with replication

[Joan Touzet]

Double-check that DNS is actually working.

Look at the CouchDB logfiles for hints here as well.

-Joan "it's always DNS" Touzet

On 2019-05-16 7:07 p.m., Mantell, Christopher Arthur wrote:

Hi Mark,


Can you replicate a database locally on the fresh install?


Also I would check the couch logs to see if there's some error that's clear 
with the replication.


Chris Mantell

Programmer

Athinoula A Martinos Center for Biomedical Imaging
Massachusetts General Hospital
Building 149 - South Central
Charlestown, MA 02129
cmant...@mgh.harvard.edu


From: Mark Richter 
Sent: Thursday, May 16, 2019 6:35:02 PM
To: user@couchdb.apache.org
Subject: RE: Need help with replication

 External Email - Use Caution

Third time - the image is here: 
https://drive.google.com/open?id=1pU3GL9cbhtLuFdqfl9kyEw5lVAwPhCjJ

Thanks (in advance).

From: Mark Richter
Sent: Thursday, May 16, 2019 3:30 PM
To: user@couchdb.apache.org
Subject: RE: Need help with replication

Ok, I tried to attach the image and that doesn't appear to work.  I also tried 
to create a gist containing the image and that also did not work.

Suggestions please?


From: Mark Richter mailto:mrich...@solarflare.com>>
Sent: Thursday, May 16, 2019 3:22 PM
To: user@couchdb.apache.org
Subject: Need help with replication

My current project is attempting to set up a couchdb cluster, but so far that 
has failed miserably.

As a fallback, we're trying to set up couchdb replication from one server to a 
backup server, but this also does not seem to work.  I have couchdb installed 
on both machines, one with a fair number of active databases, the other just a 
plain fresh installation.  No replication is working.

Here is a screenshot of the current state of the replications:

[cid:image001.png@01D50BFB.2968D290]

Can someone tell me what I'm doing wrong?

Thanks.


Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403
[Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395]

The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.
The information contained in this message is confidential and is intended for 
the addressee(s) only. If you have received this message in error, please 
notify the sender immediately and delete the message. Unless you are an 
addressee (or authorized to receive for an addressee), you may not use, copy or 
disclose to anyone this message or any information contained in this message. 
The unauthorized use, disclosure, copying or alteration of this message is 
strictly prohibited.

Re: can't connect to outside IP couchdb

[Joan Touzet]

On 2019-05-16 1:42 p.m., Rene Veerman wrote:

i use an ubuntu server and firefox on the same machine, to connect to
seductiveapps.com as shown in the initial post in this thread.

i've already got cors installed and changed the /opt/couchdb/etc/local.ini
to use bind_address = 0.0.0.0

i'm a bit stumped..


Did you restart the CouchDB process? CouchDB won't pick up an .ini file 
edit without a restart.


Use the output of `ps waux` to be sure that the start time has changed 
after a restart.


-Joan

Re: Diversity Information from iCLA?

[Joan Touzet]

I have a proposal that I'm going to run by the Board during our 
remaining face-to-face session today that may help with this.


Please Stand By. :)

-Joan

On 2019-05-16 10:43 a.m., Ross Gardler wrote:

Seems to me like we have plenty of people who feel this is a good idea, but not 
one we feel is appropriate.

Get Outlook for Android


From: Andrew Musselman 
Sent: Thursday, May 16, 2019 7:33:40 AM
To: diversity@apache.org
Subject: Re: Diversity Information from iCLA?

I get nervous when people talk about using data about me "for reasons" if I
haven't agreed to it before submitting information.

I suspect I'm not unusual in having that reaction; it could be risky just
using info "about people" without asking for their consent.

One rule of thumb for whether "using people's data" will be palatable to
them is whether they'll perceive a benefit from it, either to themselves or
to the community.

Conducting a survey would give everyone a chance to explain the motivation
and get buy-in, fwiw.

On Thu, May 16, 2019 at 04:00 Patricia Shanahan  wrote:


I would also be falsely guessed as American based on my ICLA
information. Less confusing in my case than in some, because I am a
native English speaker of European ancestry.

On 5/16/2019 3:24 AM, Aizhamal Nurmamat kyzy wrote:

It would be helpful to do the analysis, but I do think we should be

careful

on this analysis to jump into conclusions too quickly.

I moved to the USA from another country, and US address is given in the
ICLA. That is true for a good number of my friends who started getting
involved with open source as well. Including or excluding people like me

in

the  analysis would not really capture the diversity part.

So I think doing the analysis is a great idea, but we should be cautious
about the conclusions we derive from it.

Best
Aizhamal

On Wed, May 15, 2019 at 09:37 Patricia Shanahan  wrote:


On 5/15/2019 7:20 AM, Bertrand Delacretaz wrote:

Hi Awasum,

On Wed, May 15, 2019 at 3:42 PM Awasum Yannick 

wrote:

...If we really wanted to know the country/country/geographical

distribution

of our committers, the most reliable way to do it is to look at the

iCLA

files without displaying names of committers, just the countries...


I agree in principle but the lone committer from Failuristan, where
participation in Open Source can get you in trouble, would not be
happy to see that.


For several years I was over 50, female, and a student in UCSD's
Computer Science PhD program.

Considered separately, age, gender, department, and intended degree each
seems harmless. Taken together, they uniquely identified me.

I looked closely at surveys, and checked whether they had a minimum
group size policy that would protect my privacy. I would have been upset
to see information I had supplied for legal or administrative purposes
treated as research survey data without having the opportunity to decide
for myself whether or not to participate.


---
This email has been checked for viruses by AVG.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avg.com&data=02%7C01%7CRoss.Gardler%40microsoft.com%7Cdc8ae9bb93a747f8a7b608d6da0b88f4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636936140413029130&sdata=j%2BZpteft9oJj9RQYu6izTIAMKAfmsNmeUOf5rVx6FCA%3D&reserved=0


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org






-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org






-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Design doc index switching

[Joan Touzet]

Hi Garren,

+1. I actually went hunting in GitHub for an issue on this, and can't 
find one. It probably goes back to JIRA, and I don't have the energy to 
dig through that now.


The closest issue that captures this is the same thing - but for 
*databases* - and is on our official roadmap from the last summit:


  https://github.com/apache/couchdb/issues/1502

Could we consider this use case at the same time?

-Joan

On 2019-05-16 2:51 a.m., Garren Smith wrote:

Hi Everyone,

A common pattern we see for updating large indexes that can take a few days
to build, is create a new design docs with the new updated views. Then once
the new design doc is built, a user changes the new design doc’s id to the
old design doc. That way the CouchDB url for the views remain the same and
any requests to the design doc url automatically get the latest views only
once they built.

This is an effective way of managing building large indexes, but the
process is quite complicated and often users get it wrong. I would like to
propose that we move this process into CouchDB and let CouchDB handle the
actual process. From a users perspective, they would add a field to the
options of a design document that lets CouchDB know, that this build needs
to be built in the background and only replace the current index once its
built:

```
{
   "_id": "_design/design-doc-id",
   "_rev": "2-8d361a23b4cb8e213f0868ea3d2742c2",
   "views": {
 "map-view": {
   "map": "function (doc) {\n  emit(doc._id, 1);\n}"
 }
   },
   "language": "javascript",
 "options": {
 "build_and_replace": true
 }
}
```

I think this is something we could build quite effectively once we have
CouchDB running on top of FoundationDB. I don’t want to implement it for
version 1 of CouchDB on FDB, but it would be nice to keep this in mind as
we build out the map/reduce indexes.

What do you think? Any issues we might have by doing this internally?

Cheers
Garren

[jira] [Commented] (WHIMSY-260) Cannot see prior comments on PMR reports

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840688#comment-16840688
 ] 

Joan Touzet commented on WHIMSY-260:


The text of that line is the conditional below:

 

JSONStorage.fetch = function(name, block) {
  if (typeof fetch !== 'undefined' && typeof caches !== 'undefined' && 
(location.protocol == "https:" || location.hostname == "localhost")) {
    caches.open("board/agenda").then(function(cache) {
  var fetched = null;

> Cannot see prior comments on PMR reports
> 
>
> Key: WHIMSY-260
> URL: https://issues.apache.org/jira/browse/WHIMSY-260
> Project: Whimsy
>  Issue Type: Bug
>  Components: BoardAgenda
>Reporter: Joan Touzet
>Priority: Critical
> Attachments: Archive 19-05-10 16-24-02.har, MWSnap 2019-05-10, 
> 15_48_56.png
>
>
> When I browse to a given report, such as:
>    [https://whimsy.apache.org/board/agenda/2019-05-15/Lens]
> I cannot see any comments from prior meetings. I have tried the following 
> browser combinations with no luck:
>  * Firefox ESR, Linux (60.6.2)
>  * Firefox Stable, Win64 (66.0.x)
>  * Chromium, Win64 (66.0.something)
> I have tried this both with a "wide" browser (so the comments section is to 
> the right in 2-column format) and a "narrow" browser (all in a single column) 
> to no effect.
> Other board members tell me that they see these comments below the section 
> for any comments being filed for the current month.
> Screenshot attached.
> Am I missing permissions of some sort?
> This is making it hard to review reports, since I am lacking a significant 
> amount of context from prior board members' comments.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WHIMSY-262) Edit own comments

[Joan Touzet (JIRA)]

Joan Touzet created WHIMSY-262:
--

 Summary: Edit own comments
 Key: WHIMSY-262
 URL: https://issues.apache.org/jira/browse/WHIMSY-262
 Project: Whimsy
  Issue Type: New Feature
Reporter: Joan Touzet


It'd be awesome if a Director could edit her own formally-submitted comments 
thru the web interface.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Diversity Information from iCLA?

[Joan Touzet]

Awasum,

On 2019-05-15 9:42 a.m., Awasum Yannick wrote:


If we really wanted to know the country/country/geographical distribution
of our committers, the most reliable way to do it is to look at the iCLA
files without displaying names of committers, just the countries and we
will know for sure how geographically diverse we are. This will answer some
key questions like "is there a diversity problem?" and comments like "Show
me the facts supporting our lack of diversity" will be dealt with. Even if
its just one aspect of diversity(geographical).


As signed documents with legal significance to the Foundation, the iCLAs 
 have legal protections that would likely prevent such usage. Signing 
such documents usually makes them protected - I am not a lawyer, and 
would defer to legal-discuss@ / the legal JIRA instance if you really 
want to pursue this option.


-Joan

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: [GitHub] [couchdb] rgarrigue opened a new issue #2031: Debian Buster package

[Joan Touzet]

CouchDB does not rush to release binaries for Debian/Ubuntu/CentOS/RHEL 
on major x.0 releases.


It is unlikely we will publish any buster package until after its 
official promotion to stable. No release date has been set yet for 
buster, though we're aware it is in freeze status. After release, we 
will then add buster to our CI matrix and ensure regression tests pass 
properly before releasing. If history serves, you can expect the package 
roughly a month after the buster release.


If you need it running on buster sooner, you are always welcome to 
compile from scratch. Bug reports and pull requests against our CI or 
packaging repos from issues you find are always welcome.

Re: Multi-lingual project communication & recommendations

[Joan Touzet]

FYI, I misspoke here:

On 2019-05-14 4:08 p.m., Joan Touzet wrote:
Since this goes past what we want to do for just ourselves, I've renamed 
the thread. I just want to remind everyone in this discussion that the 
D&I group (in whatever official form it takes) can't set policy for the 
ASF - we can only provide recommendations to be acted upon by leadership.


The answer as to what policy D&I could, should, must, or must not be 
able to implement will come out of the action the Board takes shortly on 
where the proposal lands.


It is not a foregone conclusion that D&I "must not" set policy. But 
choosing to ask the board for that power would be a separate action that 
we would have to carefully consider.


Thanks to the Members who corrected me off-list for giving me the chance 
to correct myself publicly.


-Joan "point of order" Touzet

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Multi-lingual project communication & recommendations (was: [FAQ] Proto-FAQ question 1)

[Joan Touzet]

ecommended or required practice for the 
PMC members to try to provide those short summaries, even if it is via Google 
Translate.

Again, a restaurant analogy.  If some tourists come into your restaurant, use 
their limited English to order food, then have a conversation in their native 
language while eating, that should be allowed, and the astute restaurant worker 
will still try to pick up on whether they are enjoying the food and the 
restaurant in general.  IMO, Google Translate has worked well enough for me to 
pick up on non-English conversations on the lists and participate.  I would not 
want to have to monitor other language specific lists.  I would encourage 
everyone on our lists to use Google Translate to get a sense of the 
conversations in other languages.  I will be super happy if my project's users@ 
lists are a mix of languages.

My 2 cents,
-Alex

On 5/14/19, 9:19 AM, "Joan Touzet"  wrote:

 This is something that's been on my mind a lot recently.

 We can't come up with a way to support non-English official
 communication channels for the Foundation as Bertrand mentions, but if
 we don't allow non-official channels in other languages, as the saying
 goes, "the Internet will route around us" and just create them outside
 of the ASF.

 I, for one, would rather see those discussions happening on ASF lists if
 at all possible. Maybe we can't have a dev-chinese@project.a.o, but
 couldn't we at least support a users-chinese@project.a.o?

 I think it's equally important to consider the i18n and l10n of the
 software projects that we shepherd. This is something I want to ask the
 assembled minds in the board/officers at the face-to-face meeting this 
week.

 I know there are some woefully under-recognized solutions within the ASF
 (such as our Pootle instance, 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftranslate.apache.org%2F&data=02%7C01%7C%7Cda3f0dd6e5d34047c12408d6d88bbd79%7C84df9e7fe9f640afb435%7C1%7C0%7C636934492017566418&sdata=Y1N%2FdjHRKBSqSrGZns9QxLSJenscUnv4uUhvW4IS1H0%3D&reserved=0).
 Look how
 few projects even try to use it. This is tragic. And doing what we can
 to improve things here I feel does fall under D&I. It even meshes with
 the US non-profit mission of software for/in the public good, since the
 US does not have an official national language, and has a large
 percentage of citizens and residents who speak other languages.

 On the intake side, we should consider translation of the FAQ and other
 documents into a few languages, with reverse translations back to
 English to ensure nuance is not lost (especially for critical documents
 like the CoC, general project bylaws, and maybe some of "The Apache Way"
 stuff.) These documents can clearly be marked as "not official" so as to
 not overburden our thin legal resources to date.

 -Joan

 On 2019-05-14 12:03 p.m., Alex Harui wrote:
 > It has been interesting to me how important words are in these discussions.  In this case, the word 
"fix".  We may not be able to "fix" as in "eliminate" the requirement to communicate in 
English, but I believe we can and should encourage communities to choose their words more carefully so that 
"fluency" is not perceived as a requirement.  I already do filter my choice of words to try to avoid word 
patterns that non-US citizens may not understand since all but one of the most active committers on my project live 
outside the US.
 >
 > We might come up with other social suggestions like allowing posts in 
other languages on users@ lists, allowing posts in other languages on dev@ but 
recommending translation of the original post to English and requiring posts in 
English on private@.  That's sort of how Flex and Royale operate today without any 
official documentation of this approach.
 >
 > My observation is that restaurant workers in the US in popular tourist 
areas are generally trained to be patient with non-English-speaking customers and 
also choose their words carefully.  Why shouldn't we all take that approach at 
Apache?   Another observation is that airline pilots fly to the US from all over 
the world and communicate in English to flight controllers in the US (and other 
countries too, iIRC).   I'm fairly certain the US-based flight controllers choose 
their words carefully.  I do not think all of those pilots from other countries 
are fluent in English.  They have learned enough functional English to communicate 
on how to navigate and land an airplane.  Does/should software development at the 
ASF require an even larger English vocabulary than navigating air-space?
 >
 > My 2 cents,
 > -Alex
 >
 > On 5/14/19, 6:27 AM, &

Re: FAQ and education mailing list

[Joan Touzet]

On 2019-05-14 12:17 p.m., Patricia Shanahan wrote:

On 5/14/2019 8:18 AM, Bertrand Delacretaz wrote:
On Tue, May 14, 2019 at 5:05 PM Griselda Cuevas 
 wrote:
...The word does not have a negative connotation to me since I 
translated

it from Spanish


Thanks Gris! Indeed in English, "preaching" tends to have more of a 
religious definition, even avoiding connotative meanings.
I think maybe it needs a mention in the Question 1 response, but I am 
also thinking of a complete question and answer on the risk of 
miscommunication, especially in writing unaided by tone of voice, facial 
expressions, and body language. It is further complicated when people 
are using different dialects, or writing in a language in which they do 
not have complete native speaker fluency.


Absolutely. The CoC talks about this in detail; here's a couple of quotes:

Be inquisitive. Nobody knows everything! Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. 



Be careful in the words that we choose. Whether we are participating as 
professionals or volunteers, we value professionalism in all interactions, and 
take responsibility for our own speech.
Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion. 


https://www.apache.org/foundation/policies/conduct.html

-Joan

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: [FAQ] Proto-FAQ question 1

[Joan Touzet]

This is something that's been on my mind a lot recently.

We can't come up with a way to support non-English official 
communication channels for the Foundation as Bertrand mentions, but if 
we don't allow non-official channels in other languages, as the saying 
goes, "the Internet will route around us" and just create them outside 
of the ASF.


I, for one, would rather see those discussions happening on ASF lists if 
at all possible. Maybe we can't have a dev-chinese@project.a.o, but 
couldn't we at least support a users-chinese@project.a.o?


I think it's equally important to consider the i18n and l10n of the 
software projects that we shepherd. This is something I want to ask the 
assembled minds in the board/officers at the face-to-face meeting this week.


I know there are some woefully under-recognized solutions within the ASF 
(such as our Pootle instance, https://translate.apache.org/). Look how 
few projects even try to use it. This is tragic. And doing what we can 
to improve things here I feel does fall under D&I. It even meshes with 
the US non-profit mission of software for/in the public good, since the 
US does not have an official national language, and has a large 
percentage of citizens and residents who speak other languages.


On the intake side, we should consider translation of the FAQ and other 
documents into a few languages, with reverse translations back to 
English to ensure nuance is not lost (especially for critical documents 
like the CoC, general project bylaws, and maybe some of "The Apache Way" 
stuff.) These documents can clearly be marked as "not official" so as to 
not overburden our thin legal resources to date.


-Joan

On 2019-05-14 12:03 p.m., Alex Harui wrote:

It has been interesting to me how important words are in these discussions.  In this case, the word "fix".  
We may not be able to "fix" as in "eliminate" the requirement to communicate in English, but I 
believe we can and should encourage communities to choose their words more carefully so that "fluency" is not 
perceived as a requirement.  I already do filter my choice of words to try to avoid word patterns that non-US citizens 
may not understand since all but one of the most active committers on my project live outside the US.

We might come up with other social suggestions like allowing posts in other 
languages on users@ lists, allowing posts in other languages on dev@ but 
recommending translation of the original post to English and requiring posts in 
English on private@.  That's sort of how Flex and Royale operate today without 
any official documentation of this approach.

My observation is that restaurant workers in the US in popular tourist areas 
are generally trained to be patient with non-English-speaking customers and 
also choose their words carefully.  Why shouldn't we all take that approach at 
Apache?   Another observation is that airline pilots fly to the US from all 
over the world and communicate in English to flight controllers in the US (and 
other countries too, iIRC).   I'm fairly certain the US-based flight 
controllers choose their words carefully.  I do not think all of those pilots 
from other countries are fluent in English.  They have learned enough 
functional English to communicate on how to navigate and land an airplane.  
Does/should software development at the ASF require an even larger English 
vocabulary than navigating air-space?

My 2 cents,
-Alex

On 5/14/19, 6:27 AM, "Bertrand Delacretaz"  wrote:

 On Tue, May 14, 2019 at 3:09 PM Daniel Gruno  wrote:
 > ...It's like democracy - while not perfect, it is (I would say) the least
 > sucky way of ensuring fairness, openness and proper governance, as it is
 > the most universal (and de facto standard) language we have..
 
 +1
 
 > I do not see the need for or lack of English skills as a thing *we* can fix...
 
 Same here, I was mentioning as one invariant that does affect who

 joins our communities - or more precisely the way people contribute.
 
 -Bertrand
 
 -

 To unsubscribe, e-mail: diversity-unsubscr...@apache.org
 For additional commands, e-mail: diversity-h...@apache.org
 
 



-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org



-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: [FAQ] Proto-FAQ question 1

[Joan Touzet]

I think the point was not that the FAQ needed those things, but the ASF 
at large :D and that the different way of phrasing it was intended to 
draw attention to all of those things.


-Joan

On 2019-05-13 6:45 p.m., Patricia Shanahan wrote:
I would love truly elegant documentation. However, I am neither a 
Confluence expert nor a graphic designer. As you say, it needs a community.


Perhaps people who are good at graphic design could create frameworks 
for the FAQ and Resources? Should each of them, long term, be Wiki pages 
or pages in a D&I web site? However it is done, it cannot depend on 
graphics. There are some readers who will only have access to whatever 
text their browser can extract.


Curating the initial content is something that seems to me to need doing 
and that I think I know how to do, so I started doing it.


On 5/13/2019 3:03 PM, Matt Sicker wrote:

This might be slightly inflammatory, but how about this: do you want
non-shitty documentation? How about graphics and logos? Maybe a nice
website? Or some helpful users for support? Hard to do without community!

On Mon, May 13, 2019 at 15:14, Patricia Shanahan  wrote:


The first and most important question is something along the lines of:

--

Q: Apache does everything by e-mail. I do not know or care about the
race, ethnicity, gender, age, weight, or any other personal
characteristics of other contributors. Why are diversity and inclusion
relevant issues for Apache?

--

Here are some elements that I think should be covered in the answer. At
this point, I am going for the big picture. Please suggest improvements
and fix errors.

--

1. Subconscious bias: You know the name the contributor uses. In
addition, you may know their time zone and, from how quotes are
introduced, the language in which they do most of their e-mail 
interaction.


Research indicates that merely changing the name on a resume can affect
the probability of a call back. Although the results could in theory be
explained by deliberate racism and sexism, they seem more likely to be
due to subconscious bias.

2. It is not all e-mail: Apache contributors meet at open source
conferences, specialty technical conferences, and local gatherings. Not
being able to participate without fearing discrimination would itself be
discouraging.

3. Unintentional insult through stereotypes: This is a bigger risk in
e-mail than in face-to-face interactions.

I had someone on a mailing list use "try to explain X to someone's
aunt", where X was a difficult technical point, as an example of
futility. It invoked a stereotype of older women as lacking computer
science comprehension. As it happens, I already had two adult nephews
when I got my PhD in computer science. The writer would probably not
have said what they did in a live conversation including a grey-haired
woman.

4. Misuse of pronouns: If you know someone's preferred pronouns you know
something about their gender, and subconscious gender discrimination
becomes possible. If you don't, you may be making them cringe every time
you refer to them in an e-mail.

--

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

--

Matt Sicker 



-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org



-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Couchdb 2.3.1 python Views

[Joan Touzet]

HI Victor,

Are you running CouchDB from your command line?

If you're running it as a service, you'll need to get that environment
variable into the context for the process.

You might do better to

# chmod +x /usr/bin/couchpy

and ensuring the first line is a "shebang" of the form:

#!/usr/bin/python

or

#!/usr/bin/python3

and then make sure this is in your CouchDB running process's

export COUCHDB_QUERY_SERVER_PYTHON="/usr/bin/couchpy"

instead of running python3 and passing it the couchpy script.

If you're on Linux, look in the /proc//environ "file" to see if the
variable actually is getting set on your beam.smp CouchDB process.

-Joan

On 2019-05-13 17:46, Victor CORREIA wrote:
> Thanks Joan for your anwser.
> 
> I 've readed release notes ;-), it isn't in production platform, it's in dev.
> I'm testing couchdb 2.3.1 before upgrade critical environment.
> 
> until 2.2.1 , we used pycouchdb to generate our views in python2.
> in local.ini, i had:
> 
> [query_servers]
> python = /usr/bin/couchpy
> 
> now in couchdb 2.3.1, i must export environment variable, in my case:
> COUCHDB_QUERY_SERVER_PYTHON="/path/to/python/query/server.py with args"
> 
> i tried to put COUCHDB_QUERY_SERVER_PYTHON="/usr/bin/python3 /usr/bin/couchpy"
> i have modified in ~.bashrc for use python3 by default
> 
> but no success, so pycouchdb is compatible with views management in
> couchdb 2.3.1 ?
> if yes can you help me too resolv my problem .
> 
> thank you for your answers and comments..
> 
> Victor.
> 
> Le lun. 13 mai 2019 à 18:49, Joan Touzet  a écrit :
>>
>> Hi Victor,
>>
>> The way external view servers are invoked has changed in 2.3.x and up,
>> due to security reasons. You should always read the release notes before
>> blindly upgrading.
>>
>> The release notes for 2.3.x are here:
>>
>> http://docs.couchdb.org/en/stable/whatsnew/2.3.html#upgrade-notes
>>
>> -Joan
>>
>> On 2019-05-13 10:45, Victor CORREIA wrote:
>>> Hi couchdb Users.
>>>
>>> I used couchdb and i was upgraded couchdb from 2.2.1 to 2.3.1 , but pb
>>> my python views don't works.
>>>
>>> I have try to change like doc , but no success.
>>>
>>> export COUCHDB_QUERY_SERVER_PYTHON="/path/to/python/query/server.py with 
>>> args"
>>>
>>> I tried;
>>> I have install python3.
>>> export COUCHDB_QUERY_SERVER_PYTHON="/usr/bin/python3 /usr/bin/couchpy"
>>>
>>> but i have Error running query. Reason: (unknown_query_language)
>>> python, on Fauxton when i try  my custom views.
>>>
>>> do you have an example or more information to resolv my problem  ?
>>>
>>> thanks..
>>>
>>> Victor.
>>>
>>

Re: FAQ and education mailing list

[Joan Touzet]

On 2019-05-13 16:37, Griselda Cuevas wrote:
> Teaching by preaching is what will earn us respect, credibility and
> authority to speak of this topic.

Gris, can I ask what you mean by "preaching" in this context?

For me this has a very negative connotation and feels out of place in a
secular organisation such as the ASF.

-Joan


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Couchdb 2.3.1 python Views

[Joan Touzet]

Hi Victor,

The way external view servers are invoked has changed in 2.3.x and up,
due to security reasons. You should always read the release notes before
blindly upgrading.

The release notes for 2.3.x are here:

http://docs.couchdb.org/en/stable/whatsnew/2.3.html#upgrade-notes

-Joan

On 2019-05-13 10:45, Victor CORREIA wrote:
> Hi couchdb Users.
> 
> I used couchdb and i was upgraded couchdb from 2.2.1 to 2.3.1 , but pb
> my python views don't works.
> 
> I have try to change like doc , but no success.
> 
> export COUCHDB_QUERY_SERVER_PYTHON="/path/to/python/query/server.py with args"
> 
> I tried;
> I have install python3.
> export COUCHDB_QUERY_SERVER_PYTHON="/usr/bin/python3 /usr/bin/couchpy"
> 
> but i have Error running query. Reason: (unknown_query_language)
> python, on Fauxton when i try  my custom views.
> 
> do you have an example or more information to resolv my problem  ?
> 
> thanks..
> 
> Victor.
> 

Re: FAQ and education mailing list

[Joan Touzet]

Couple of thoughts - sorry for being brief, and really not trying to
bikeshed here:

* We need someone to shepherd this, thank you Patricia for volunteering!

  Generally my opinion is that the work of building the content should
  fall to those who have learned, not the explainers, who are the ones
  burdened with the heaviest emotional load dealing with the concern
  trolls. Naomi pointed this out in another thread. To that end I saw
  what looked like volunteers in Rich and/or Ross. ;)

* A protected page on our wiki would be a good place to house this. Or,
  something under git where we can do pull requests and reviews on
  GitHub. The problem with the latter is the potential as a vector for
  drive-by vandalism and abuse. Either way, it should be a sub-set of
  pages or resources so their content doesn't overwhelm needs of our
  wiki/git repos for our actual business.

* Having Ezmlm point to the wiki / git page would be a good idea. I'd
  worry about putting the full text into the autoresponse from
  diversity-help; it might feel like being brow-beaten for a newcomer.

* Some excellent resources are below, including a final article on why
  "If you don't teach me, how can I learn?" is a tried-and-true
  derailing technique and not an honest request for assistance. I'd
  think that these kinds of articles would be good as a "Resources"
  section, which I think is generally better than a FAQ since it can
  be too narrow, and thus be "game theoried"/"rule lawyered" around
  by the determined derailer.

  * https://geekfeminism.wikia.org/wiki/Geek_Feminism_Wiki
  * https://communitymgt.fandom.com/wiki/Community_Management_Wiki
  *
https://medium.com/the-nonprofit-revolution/8-ways-people-of-color-are-tokenized-in-nonprofits-32138d0860c1
  *
http://interpretereducation.org/wp-content/uploads/2014/04/Characteristics-of-the-Opressed_110314.pdf
  *
https://www.salon.com/2015/04/14/black_people_are_not_here_to_teach_you_what_so_many_white_americans_just_cant_grasp_partner/

-Joan "will there ever be a last time to answer some questions" Touzet

On 2019-05-13 10:35, Matt Sicker wrote:
> I’m not sure how the technical feature works, but mailing lists can set up
> an FAQ. Ezmlm allows you to send a message to diversity-h...@apache.org
> which could theoretically be used here.
> 
> On Mon, May 13, 2019 at 08:18, Patricia Shanahan  wrote:
> 
>> I picked the name without much thought, so it can almost certainly be
>> improved.
>>
>> On 5/13/2019 6:04 AM, Naomi Slater wrote:
>>> I think this is a great idea
>>>
>>> I hope this isn't bikeshedding, but perhaps we should choose a different
>>> name. I say this because I'd like to be able to direct someone to this
>>> other list without it sounding like I'm telling them they need to "get an
>>> education"
>>>
>>> perhaps diversity-meta@ (because it would be a place to
>>> discuss/question/enquire about the diversity effort at Apache, in
>> contrast
>>> with this list, which is a place to actually carry out the diversity
>> effort
>>> at Apache)
>>>
>>>
>>>
>>>
>>>
>>> On Sat, 11 May 2019 at 17:19, Patricia Shanahan  wrote:
>>>
   From my experience with technical newsgroups and mailing lists,
 including those intended for experts, a FAQ can be invaluable in dealing
 with the questions the long term participants have seen far too often.
 Craig Russell has suggested having one for our diversity effort. I am
 sure there are other somewhat relevant FAQ's out there, and I will look
 for them, but I think we need something tuned to ASF's mailing list and
 do-ocracy culture.

 When someone shows up with an old, familiar, question there would be no
 need to argue about whether they are a troll or just ignorant. You
 simply refer them to the FAQ and then ignore them unless and until they
 ask a question it does not answer, in a way that shows they have read
 and considered it.

 Even given my medical situation, I think I could at least make a start
 on organizing a FAQ. For that, I need two types of input: links to good
 self-education sources, and sample questions-and-answers.

 As I have already pointed out, I am not myself an expert. Of course, I
 will read referenced material to improve my own education. I got started
 in the computer industry at a time when people accepted women in
 technical leadership roles. By 1980, I was project leader for the
 technical core of NCR's VRX operating system, and it was too late for
 anyone to tell me I didn't belong.

 Unfortunately, the best sample questions will be exactly the ones many
 of you have been dealing with for years. The more likely a question is
 to be the opening salvo of troll visit, the more important it will be to
 answer it in the FAQ. I hope some of the experts will be willing to
 contribute their experience.

 I don't want my FAQ-collection effort to get in the way of getting
 things done

Re: Apache people, Native Americans

[Joan Touzet]

It depends which sub-group you are talking about, and whether you are
referring to current or former relationships.

The Jicarilla Apache in New Mexico actively refer to themselves as a
Nation, as do the Yavapai-Apache Nation, the San Carlos Apache Nation
and the Fort McDowell Yavapai Nation. Many other tribes do not use the
term Nation, or are not referred to as a Nation by state or federal
authorities (though they, themselves, may use the term).

Some of this has resulted from being "downgraded" through the erosion of
US treaty promises over the years, so the term is both nebulous and
emotionally charged. For instance, some (US) historians use the term
Nation only to refer to pre-forced removal Apache Nations. Legally,
however, the terms nation, tribe, community, Rancheria and band have
been used interchangeably in Indian treaties and statutes.[1]

The fact that the term "Apache" applies to multiple subgroups of
different sizes will make it difficult for us to get buy-in from all of
them, and makes it unclear whether or not it makes sense to try.

The fact also appears to be that we evolved from "a patchy server" to
"Apache", and then co-opted the feather logo and colour scheme as our
own, without asking and getting clear permission from even a subset
first. That's a choice we have to live with today.

On a more positive note, the San Carlos Apache Chamber of Commerce
displays our logo and a link to our website on their website:

http://www.sancarlosapache.com/Apache_Chamber_of_Commerce.htm

I wouldn't call this outright endorsement, but I'd say it's at least a
sign that there is no animosity. Let's not pick the scab off of this wound.

-Joan "far too many Native American books on the shelf" Touzet

[1]: Pevar, Stephen L. The Rights of Indians and Tribes. Fourth ed.
Oxford: Oxford UP, 2012.

On 2019-05-13 10:41, Matt Sicker wrote:
> According to Wikipedia, Apache are made up of several tribes. It doesn’t
> sound like an individual tribe, so “nation” sort of makes sense, though I’m
> not familiar with their specific terminology.
> 
> On Mon, May 13, 2019 at 07:11, Rich Bowen  wrote:
> 
>>
>>
>> On 5/13/19 12:11 AM, Kenneth Knowles wrote:
>>> "subscribe"
>>>
>>> This comes up for me pretty much every time I explain my work/life to
>>> someone who has not yet heard of the ASF (if they don't mention it, that
>> is
>>> sort of worse). Reading Mark's comment I had the same question as Rich. I
>>> would very much like to know the answer and the details.
>>
>> I'm intrigued that it comes up every time (it almost never does, for me)
>> and also that you think that it's bad when it doesn't (Why?).
>>
>> If this is something you consider important, I'd encourage you to take
>> the references posted by Mark and run with them. Do the research. Ask
>> Brian. See what you can find out.
>>
>>> On 5/10/19 4:22 PM, Mark Thomas wrote:
>> In the private archives I found:
>>
>> - A reference that at OSCON 09 a member of the Apache Nation politely
>>mentioned that they  should be referred to as the Apache Nation and
>>not a tribe.
>>
>> Which is the opposite of the terminology used on their official website,
>> https://mescaleroapachetribe.com/
>>
>> The word "tribe" is one that I avoid, because people do feel that it has
>> negative connotations. However, consistently over the years, I've seen
>> that the people who are offended by it are, for the most part, not the
>> people being referred to.
>>
>> --
>> Rich Bowen - rbo...@rcbowen.com
>> http://rcbowen.com/
>> @rbowen
>>
>> -
>> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
>> For additional commands, e-mail: diversity-h...@apache.org
>>
>> --
> Matt Sicker 
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

[jira] [Updated] (WHIMSY-260) Cannot see prior comments on PMR reports

[Joan Touzet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WHIMSY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joan Touzet updated WHIMSY-260:
---
Attachment: Archive 19-05-10 16-24-02.har

> Cannot see prior comments on PMR reports
> 
>
> Key: WHIMSY-260
> URL: https://issues.apache.org/jira/browse/WHIMSY-260
> Project: Whimsy
>  Issue Type: Bug
>  Components: BoardAgenda
>    Reporter: Joan Touzet
>Priority: Critical
> Attachments: Archive 19-05-10 16-24-02.har, MWSnap 2019-05-10, 
> 15_48_56.png
>
>
> When I browse to a given report, such as:
>    [https://whimsy.apache.org/board/agenda/2019-05-15/Lens]
> I cannot see any comments from prior meetings. I have tried the following 
> browser combinations with no luck:
>  * Firefox ESR, Linux (60.6.2)
>  * Firefox Stable, Win64 (66.0.x)
>  * Chromium, Win64 (66.0.something)
> I have tried this both with a "wide" browser (so the comments section is to 
> the right in 2-column format) and a "narrow" browser (all in a single column) 
> to no effect.
> Other board members tell me that they see these comments below the section 
> for any comments being filed for the current month.
> Screenshot attached.
> Am I missing permissions of some sort?
> This is making it hard to review reports, since I am lacking a significant 
> amount of context from prior board members' comments.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (WHIMSY-260) Cannot see prior comments on PMR reports

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837581#comment-16837581
 ] 

Joan Touzet commented on WHIMSY-260:


No requests to that URL. Instead I get:

SecurityError: The operation is insecure. app-es5.js:7

The HAR file for the initial page load + refresh is attached, if that helps you 
any.

> Cannot see prior comments on PMR reports
> 
>
> Key: WHIMSY-260
> URL: https://issues.apache.org/jira/browse/WHIMSY-260
> Project: Whimsy
>  Issue Type: Bug
>  Components: BoardAgenda
>    Reporter: Joan Touzet
>Priority: Critical
> Attachments: Archive 19-05-10 16-24-02.har, MWSnap 2019-05-10, 
> 15_48_56.png
>
>
> When I browse to a given report, such as:
>    [https://whimsy.apache.org/board/agenda/2019-05-15/Lens]
> I cannot see any comments from prior meetings. I have tried the following 
> browser combinations with no luck:
>  * Firefox ESR, Linux (60.6.2)
>  * Firefox Stable, Win64 (66.0.x)
>  * Chromium, Win64 (66.0.something)
> I have tried this both with a "wide" browser (so the comments section is to 
> the right in 2-column format) and a "narrow" browser (all in a single column) 
> to no effect.
> Other board members tell me that they see these comments below the section 
> for any comments being filed for the current month.
> Screenshot attached.
> Am I missing permissions of some sort?
> This is making it hard to review reports, since I am lacking a significant 
> amount of context from prior board members' comments.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WHIMSY-260) Cannot see prior comments on PMR reports

[Joan Touzet (JIRA)]

Joan Touzet created WHIMSY-260:
--

 Summary: Cannot see prior comments on PMR reports
 Key: WHIMSY-260
 URL: https://issues.apache.org/jira/browse/WHIMSY-260
 Project: Whimsy
  Issue Type: Bug
  Components: BoardAgenda
Reporter: Joan Touzet
 Attachments: MWSnap 2019-05-10, 15_48_56.png

When I browse to a given report, such as:

   [https://whimsy.apache.org/board/agenda/2019-05-15/Lens]

I cannot see any comments from prior meetings. I have tried the following 
browser combinations with no luck:
 * Firefox ESR, Linux (60.6.2)
 * Firefox Stable, Win64 (66.0.x)
 * Chromium, Win64 (66.0.something)

I have tried this both with a "wide" browser (so the comments section is to the 
right in 2-column format) and a "narrow" browser (all in a single column) to no 
effect.

Other board members tell me that they see these comments below the section for 
any comments being filed for the current month.

Screenshot attached.

Am I missing permissions of some sort?

This is making it hard to review reports, since I am lacking a significant 
amount of context from prior board members' comments.

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Bug in board agenda

[Joan Touzet]

Pretty sure this is operator error on my part and you can ignore it. If 
it occurs again I'll be in touch.


-Joan

On 2019-05-09 9:39 p.m., Sam Ruby wrote:

I'll need more information.  The code appears to be correct:

https://github.com/apache/whimsy/blob/afef6e527ab4a681fece2feb231fe2f2b72eb36f/www/board/agenda/views/actions/email.json.rb#L12

Furthermore, I ran a test, and you can see the result:

https://lists.apache.org/thread.html/2cae886fb030eaf0e3bda4b2b913aacbec3f4aa4715593ad71ba44ad@%3Cprivate.whimsical.apache.org%3E

- Sam Ruby

On Thu, May 9, 2019 at 8:13 PM Craig Russell  wrote:


When using the (send email) button on a report, a window pops up and allows the 
user to change to: cc: subject: and body.

But it doesn't show (and hence doesn't allow the user to change) the from: 
field of the email.

Joan sent email that ended up in moderation because the from: was from an unregistered 
address Joan Touzet mailto:jo...@atypical.net>>.

Two comments: why isn't from: able to be edited by the user? And where did the 
email address come from? Shouldn't it be the agenda user's Apache 
i...@apache.org?

Regards,

Craig


Begin forwarded message:

From: Joan Touzet 
Subject: Re: MODERATE for bo...@apache.org
Date: May 9, 2019 at 2:38:52 PM PDT
To: Craig Russell 

I had Sam add a new feature for me, since browser-mail client
integration is broken on my desktop and the email gets created with no
body content.

Try holding Shift or Ctrl while clicking on that button!

That's the method I normally use now. Very convenient. And it took him
almost no time to implement.

Thanks again for the help!

-Joan


Craig L Russell
c...@apache.org

Re: FOSS efforts in measuring diversity & inclusion

[Joan Touzet]

Hey Shane,

On 2019-05-09 17:36, Shane Curcuru wrote:> Along with re-running our own
committer survey, there are plenty of
> resources and existing frameworks to consider for what or how we might
> want to approach research questions around D&I.
[snip]

Thanks for posting about these here. I've mentioned CHAOSS elsewhere (I
think it was on members@) and talked about Outreachy at length during my
ApacheCon Montreal talk on D&I last year. I'd love to see us get
involved in both more deeply. I also mentioned the Recurse Center, who
have some simple processes and beahvioural changes that I feel would do
well here, given our current philosophies.

Outreachy is especially noteworthy, as they've measurably increased
diverse contribution to the Linux kernel in a way that was accepted by
that (notoriously reactionary) community. By any metric, this is a
success - and is a great counterexample to people who believe that
"casting the net wider" translates to "lowering your standards."

My slides, an audio recording, and a full talk transcript are online,
and I'll keep linking them until people get sick of it:


https://speakerdeck.com/wohali/building-and-sustaining-inclusive-communities

https://feathercast.apache.org/2018/09/29/building-and-sustaining-inclusive-communities-joan-touzet/
  https://wohali.dreamwidth.org/55736.html

The flipside to the Outreachy story is that the Linux kernel community
could be, well, more welcoming. So could we. I am eager to get that
discussion started.

-Joan


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Cross-platform support update and request for advice

[Joan Touzet]

Thanks Adam! I especially want to recognize the support of the
Packet.net "Works on ARM" team, who drove the aarch64 CI/build support,
which in turn created the scripting necessary for multi-arch CI runs.

So if I commit a PR that ups all timeouts by 10x, what's the worst that
will happen? Tests that already have a very high timeout may take
significantly longer to timeout. For instance, attachment write timeouts
are currently 10s, which would become 100s.

I guess the worst that can happen is we find some badly written test
cases... ;)

Since this is the easiest path forward, I'll give it a shot and report
back. It may be...a large set of PRs, though, since we're talking about
fixing the timeouts across all the sub-repos, unless I can work out how
to tweak eunit's 5s default timeout at a global level.

-Joan

On 2019-05-09 15:34, Adam Kocoloski wrote:
> This is indeed great news.
> 
> I’m afraid I don’t have a strong opinion on how to make the tests more 
> resilient to running in an emulated environment. Any of your suggestions are 
> acceptable to me, assuming we can keep ppc64le support in scope.
> 
> Adam
> 
>> On May 4, 2019, at 12:08 AM, Joan Touzet  wrote:
>>
>> Hi again,
>>
>> With the support of ASF Infra, we now are in a position to run arbitrary 
>> alternative platforms in our CI builds. This is great news for the people 
>> who have been waiting for ARM (aarch64), PowerPC/POWER (ppc64le), mainframe 
>> (s390x), and other architecture supports.
>>
>> However, we have a challenge. Emulating other architectures is necessarily 
>> slower than running natively on provided hardware. I ran some measurements 
>> today, and found that we're not able to pass our test suites because tests 
>> are timing out.
>>
>> For example, on native x86_64 hardware, this test finishes in under half a 
>> second:
>>
>>b64url_tests: encode_binary_test...[0.372s] ok
>>
>> Running the same test on aarch64, being emulated on the same x86_64 machine:
>>
>>b64url_tests: encode_binary_test...[4.493 s] ok
>>
>> or 12x longer. The next test (decode_iolist_test) fails, presumably because 
>> it hits a 5s timeout period.
>>
>> I need advice from the list. Should we:
>>
>> * Increase the test timeouts significantly so these tests can complete
>> * Restrict ourselves to running only on actual hardware (which limits us
>>  only to aarch64, and at a stretch, ppc64le)
>> * Remove test timeouts entirely, rewriting the ones that wait forever to
>>  do something different
>> * Something else that I haven't mentioned
>>
>> Having regression testing on a variety of platforms is something that is of 
>> benefit to the project; we've ignored it for too long.
>>
>> -Joan
> 

Re: Sad state of Jenkins CI - please help fix our eunit tests!

[Joan Touzet]

Thanks for the officer, Serge, but unless you're an IBM employee, you
won't be allowed to help!

Because IBM is providing the hardware, they are also taking
responsibility for provisioning the Jenkins workers on that box. This
was a condition of them providing the machine: that they would retain
full control outside of Jenkins, and wouldn't be providing credentials
to others. They already have their own automated provisioning
infrastructure (which, coincidentally, is Chef-based) and team to manage
it. IBMers, speak up if I'm wrong here.

Our CouchDB build process for Jenkins runs in Docker containers as
defined over here:

https://github.com/apache/couchdb-ci

and is driven by the top-level Jenkins file in the CouchDB main repo.
This is how we avoid having to manage CouchDB dependencies on the
Jenkins hardware, and makes the job of provisioning Jenkins workers a
**LOT** easier. (They just need to install Docker, Java, Jenkins, qemu,
and a couple of other support packages, plus deploy the Jenkins secret
that allows each worker to register with the ASF's build master. Simples.)

If you have suggestions for improvement on the CouchDB CI repo, or want
to help with expanding it to support other configurations, pull requests
are always welcome. :D

Cheers,
Joan "moar CI" Touzet

On 2019-05-09 15:04, salsa-...@tut.by wrote:
> I can help to create automated provisioning of the system with the help of 
> Chef software.
> 
> Serge
> 
> 02.05.2019, 23:48, "Joan Touzet" :
>> Hi everyone,
>>
>> Lately, our Jenkins CI runs on master (after merges) have been failing a
>> lot:
>>
>> https://s.apache.org/yuwY
>>
>> Just in the last run (#537), we have failures in eunit tests for
>> couch_mrview, mem3 and ddoc_cache that need active investigation. [1]
>>
>> Arguably, the reason no one is actively monitoring this and fixing the
>> tests is because Jenkins does not (yet) gate commits from landing on master.
>>
>> This will change in the not-too-distant future. Travis CI has been
>> slower and slower as of late, and with ownership/leadership change of
>> Travis (the company) there's some trepidation in the community at large
>> about its long-term survivability as well.
>>
>> IBM has graciously committed to a targeted hardware donation for build
>> machines for our CI needs, to help us get runs done faster and in a
>> controlled environment. I'll be working with them once that machine
>> arrives to set up the new CI environment and ensure it does what we all
>> expect. If anyone has any input on what that should look like, do reply
>> to this email and let me know.
>>
>> Fixing Jenkins also will fix our broken snapshot package builds, which
>> very soon *will include ARM64 support* that the community has been
>> asking for, for a long time. Until we have regular greens on the board
>> for ARM64, I'm not willing to approve greenlighting public packages or a
>> Docker container for this platform. (Same goes for other platforms.)
>>
>> In short: *PLEASE HELP FIX THE FAILING TESTS*. If you want a bug per
>> failing test, I can do that, let me know.
>>
>> -Joan "all green all the time?" Touzet
>>
>> [1]: The failure in 537 on CentOS 7 comes from my recent image rebuild,
>> and CentOS's/EPEL's very recent decision to drop the python3 alias in
>> favour of version-specific ones (python3.4, python3.6). I'll add a
>> workaround for this via a /usr/local symlink in the image today.

Re: Diversity in a diverse world

[Joan Touzet]

On 2019-05-09 15:27, Geertjan Wielenga wrote:
> I'm not assuming at all that a hijab signifies sexism

Point of clarification: the women you described were wearing *burkas*,
not hijabs or niqabs.

https://www.bbc.co.uk/newsround/24118241

I'll comment more thoroughly on this thread later.

-Joan


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: D&I Strategy Design Document, please collaborate

[Joan Touzet]

Gris, point of order,

Do you mean you want to migrate it to GH before you finish receiving
comments, etc.?

Or is the conversion process to occur after 11PM PT tomorrow?

-Joan

On 2019-05-09 15:18, Gris Cuevas wrote:
> Hi folks - anyone interested in helping me migrate the design doc to GitHub?
> 
> On 2019/05/04 06:55:19, Gris Cuevas  wrote: 
>> Hi Everyone, 
>>
>> I drafted the initial strategy design doc [1] and I'd like to invite folks 
>> reading and folks who have expressed interest in contributing to collaborate 
>> as follows: 
>>
>> 1) Add, elaborate on and own aspects missing in the current outline (author, 
>> please request edit access)
>> 2) Comment, question, challenge, enrich or edit current outline 
>> (collaborator, add comments)
>>
>> The draft would be open to collaboration until 05/10 11:00 PM PST. 
>>
>> I encourage folks to contribute in other aspects such as text editing, spell 
>> checking, language checking, design, etc. This is an important document as 
>> things like this help folks with other backgrounds to digest the information 
>> we present here. 
>>
>> An important point I want to take from this document are the diversity and 
>> inclusion dimensions. I will be using these to guide our work on other 
>> ongoing initiatives such as the survey and how we start to communicate our 
>> efforts. 
>>
>> Thanks, 
>> Gris
>>
>> [1] 
>> https://docs.google.com/document/d/1FXMDFwFbb0pFvTNZyKklf2qvXGh6YNuHOMQYSAi4tiE/edit#
>>
>> -
>> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
>> For additional commands, e-mail: diversity-h...@apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: diversity-unsubscr...@apache.org
> For additional commands, e-mail: diversity-h...@apache.org
> 


-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Sad state of Jenkins CI - please help fix our eunit tests!

[Joan Touzet]

Bumping this thread because:

1. Travis CI is becoming increasingly unusable and is blocking valid
   PRs from merging.
2. Removing Travis and not putting any gate on merging PRs is, to me,
   an unacceptable medium-to-long term solution.
3. We're very close to having our own hardware to run Jenkins CI runs
   instead of Travis.
4. It won't fix the problem of PRs being blocked because these test
   cases are still failing >80% of the time in Jenkins as well as
   Travis.
5. It'll get worse when we enable cross-platform builds; see my other
   thread.

Fix the tests, or everyone loses.

-Joan "I asked nicely, now I'm telling you" Touzet



On 2019-05-02 16:41, Joan Touzet wrote:
> Hi everyone,
> 
> Lately, our Jenkins CI runs on master (after merges) have been failing a
> lot:
> 
> https://s.apache.org/yuwY
> 
> Just in the last run (#537), we have failures in eunit tests for
> couch_mrview, mem3 and ddoc_cache that need active investigation. [1]
> 
> Arguably, the reason no one is actively monitoring this and fixing the
> tests is because Jenkins does not (yet) gate commits from landing on master.
> 
> This will change in the not-too-distant future. Travis CI has been
> slower and slower as of late, and with ownership/leadership change of
> Travis (the company) there's some trepidation in the community at large
> about its long-term survivability as well.
> 
> IBM has graciously committed to a targeted hardware donation for build
> machines for our CI needs, to help us get runs done faster and in a
> controlled environment. I'll be working with them once that machine
> arrives to set up the new CI environment and ensure it does what we all
> expect. If anyone has any input on what that should look like, do reply
> to this email and let me know.
> 
> Fixing Jenkins also will fix our broken snapshot package builds, which
> very soon *will include ARM64 support* that the community has been
> asking for, for a long time. Until we have regular greens on the board
> for ARM64, I'm not willing to approve greenlighting public packages or a
> Docker container for this platform. (Same goes for other platforms.)
> 
> 
> In short: *PLEASE HELP FIX THE FAILING TESTS*. If you want a bug per
> failing test, I can do that, let me know.
> 
> -Joan "all green all the time?" Touzet
> 
> 
> [1]: The failure in 537 on CentOS 7 comes from my recent image rebuild,
> and CentOS's/EPEL's very recent decision to drop the python3 alias in
> favour of version-specific ones (python3.4, python3.6). I'll add a
> workaround for this via a /usr/local symlink in the image today.
> 

Re: [VOTE] ComDev supports formation of D&I committee

[Joan Touzet]

Not sure if it's binding (I'm not on the ComDev PMC) but +1 from me.

-Joan

On 2019-05-04 7:52 p.m., Ross Gardler wrote:

+1


From: Shane Curcuru 
Sent: Saturday, May 4, 2019 4:00 PM
To: dev@community.apache.org
Subject: Re: [VOTE] ComDev supports formation of D&I committee

Myrle Krantz wrote on 5/4/19 6:06 PM:

I propose that ComDev submmit the following statement to the board:

"The ComDev PMC hereby requests that the board create a President's
committee tasked with supporting our communities in their efforts to be
diverse and welcoming places, and tasked with helping the ASF formulate a
strategy to improve our diversity and inclusiveness.  The ComDev PMC
likewise formally requests that the new committee look for ways in which
ComDev can support our progress in these areas."

Here's my +1.


+1 also.

Do you want to s/support our progress/support progress/?  (Or am I the
one misparsing the pronoun?)

--

- Shane
   Community Development PMC
   The Apache Software Foundation

-
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



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

Re: Docker Hub security breach and CouchDB image update

[Joan Touzet]

You can use the downstream "official" images for that:

https://hub.docker.com/_/couchdb?tab=tags


On 2019-05-04 11:05 a.m., Jonathan Hall wrote:
I wonder if this step is strictly necessary? I was using many of these 
old images in my CI/CD pipeline for kivik. Perhaps I'm the only person 
doing such a thing, but I do find it valuable to test my library against 
old versions, to ensure the highest level of compatibility, even with 
unsupported images.


Maybe a compromise, to discourage use of these images, would be to make 
these old images still available, but with a different tag name 
(unsupported-1.6.1, for example)?


What do you think?

Jonathan


On 4/30/19 11:47 PM, Joan Touzet wrote:

* Removed all tags that are no longer supported or have known security
   issues. This includes versions 1.6.*, 1.7.1, 2.0.*, 2.1.*, and 2.2.*.

Cross-platform support update and request for advice

[Joan Touzet]

Hi again,

With the support of ASF Infra, we now are in a position to run arbitrary 
alternative platforms in our CI builds. This is great news for the 
people who have been waiting for ARM (aarch64), PowerPC/POWER (ppc64le), 
mainframe (s390x), and other architecture supports.


However, we have a challenge. Emulating other architectures is 
necessarily slower than running natively on provided hardware. I ran 
some measurements today, and found that we're not able to pass our test 
suites because tests are timing out.


For example, on native x86_64 hardware, this test finishes in under half 
a second:


b64url_tests: encode_binary_test...[0.372s] ok

Running the same test on aarch64, being emulated on the same x86_64 machine:

b64url_tests: encode_binary_test...[4.493 s] ok

or 12x longer. The next test (decode_iolist_test) fails, presumably 
because it hits a 5s timeout period.


I need advice from the list. Should we:

* Increase the test timeouts significantly so these tests can complete
* Restrict ourselves to running only on actual hardware (which limits us
  only to aarch64, and at a stretch, ppc64le)
* Remove test timeouts entirely, rewriting the ones that wait forever to
  do something different
* Something else that I haven't mentioned

Having regression testing on a variety of platforms is something that is 
of benefit to the project; we've ignored it for too long.


-Joan

Re: Sad state of Jenkins CI - please help fix our eunit tests!

[Joan Touzet]

Hi Garren,

Spoke too soon - we have a single failure in the elixir test suite you 
can help with. See below:


https://builds.apache.org/blue/organizations/jenkins/CouchDB/detail/jenkins-arm-anywhere/8/pipeline/60

[2019-05-03T22:49:38.382Z] ReduceTest

[2019-05-03T22:49:38.382Z]   * test More complex array key view row testing
  * test More complex array key view row testing (185.5ms)

[2019-05-03T22:49:38.382Z]

[2019-05-03T22:49:38.382Z]   1) test More complex array key view row 
testing (ReduceTest)


[2019-05-03T22:49:38.382Z]  test/reduce_test.exs:70

[2019-05-03T22:49:38.382Z]  Assertion with == failed

[2019-05-03T22:49:38.382Z]  code:  assert 
Couch.get("/#{db_name}").body()["doc_count"] == total_docs


[2019-05-03T22:49:38.382Z]  left:  11

[2019-05-03T22:49:38.382Z]  right: 12

[2019-05-03T22:49:38.382Z]  stacktrace:

[2019-05-03T22:49:38.382Z]test/reduce_test.exs:99: anonymous 
fn/4 in ReduceTest."test More complex array key view row testing"/1


[2019-05-03T22:49:38.382Z](elixir) lib/enum.ex:2941: 
Enum.reduce_range_inc/4


[2019-05-03T22:49:38.382Z]test/reduce_test.exs:80: anonymous 
fn/4 in ReduceTest."test More complex array key view row testing"/1


[2019-05-03T22:49:38.382Z](elixir) lib/enum.ex:2941: 
Enum.reduce_range_inc/4


[2019-05-03T22:49:38.383Z]test/reduce_test.exs:79: (test)


On 2019-05-03 2:38 p.m., Joan Touzet wrote:

Oops, my replies went to each of you personally.

Thanks to both Garren and Peng Hui for their offers!

Jenkins fails on EUnit, which means it doesn't get to the Elixir tests, 
so we don't know if they're failing. The EUnit tests need fixing with 
priority.


-Joan

On 2019-05-03 5:53 a.m., Peng Hui Jiang wrote:

Hi Joan,

Me too. I can work on some of them on coming Sunday. One of them in 
couch_mrview is due to timedout.


    couch_mrview_purge_docs_fabric_tests:106: 
test_purge_hook_before_compaction...*timed out*



Best regards,
Peng Hui

Inactive hide details for Garren Smith ---03/05/2019 04:32:39 PM---Hi 
Joan, I will be able to help later next week. If you coulGarren Smith 
---03/05/2019 04:32:39 PM---Hi Joan, I will be able to help later next 
week. If you could let me know of any


From: Garren Smith 
To: dev@couchdb.apache.org
Date: 03/05/2019 04:32 PM
Subject: Re: Sad state of Jenkins CI - please help fix our eunit tests!





Hi Joan,

I will be able to help later next week. If you could let me know of any
failing elixir tests I can start there.

Cheers
Garren

On Thu, May 2, 2019 at 10:48 PM Joan Touzet  wrote:

 > Hi everyone,
 >
 > Lately, our Jenkins CI runs on master (after merges) have been 
failing a

 > lot:
 >
 > https://s.apache.org/yuwY
 >
 > Just in the last run (#537), we have failures in eunit tests for
 > couch_mrview, mem3 and ddoc_cache that need active investigation. [1]
 >
 > Arguably, the reason no one is actively monitoring this and fixing the
 > tests is because Jenkins does not (yet) gate commits from landing on
 > master.
 >
 > This will change in the not-too-distant future. Travis CI has been
 > slower and slower as of late, and with ownership/leadership change of
 > Travis (the company) there's some trepidation in the community at 
large

 > about its long-term survivability as well.
 >
 > IBM has graciously committed to a targeted hardware donation for build
 > machines for our CI needs, to help us get runs done faster and in a
 > controlled environment. I'll be working with them once that machine
 > arrives to set up the new CI environment and ensure it does what we 
all
 > expect. If anyone has any input on what that should look like, do 
reply

 > to this email and let me know.
 >
 > Fixing Jenkins also will fix our broken snapshot package builds, which
 > very soon *will include ARM64 support* that the community has been
 > asking for, for a long time. Until we have regular greens on the board
 > for ARM64, I'm not willing to approve greenlighting public packages 
or a

 > Docker container for this platform. (Same goes for other platforms.)
 >
 >
 > In short: *PLEASE HELP FIX THE FAILING TESTS*. If you want a bug per
 > failing test, I can do that, let me know.
 >
 > -Joan "all green all the time?" Touzet
 >
 >
 > [1]: The failure in 537 on CentOS 7 comes from my recent image 
rebuild,

 > and CentOS's/EPEL's very recent decision to drop the python3 alias in
 > favour of version-specific ones (python3.4, python3.6). I'll add a
 > workaround for this via a /usr/local symlink in the image today.
 >
 >

Re: Sad state of Jenkins CI - please help fix our eunit tests!

[Joan Touzet]

Oops, my replies went to each of you personally.

Thanks to both Garren and Peng Hui for their offers!

Jenkins fails on EUnit, which means it doesn't get to the Elixir tests, 
so we don't know if they're failing. The EUnit tests need fixing with 
priority.


-Joan

On 2019-05-03 5:53 a.m., Peng Hui Jiang wrote:

Hi Joan,

Me too. I can work on some of them on coming Sunday. One of them in 
couch_mrview is due to timedout.


    couch_mrview_purge_docs_fabric_tests:106: 
test_purge_hook_before_compaction...*timed out*



Best regards,
Peng Hui

Inactive hide details for Garren Smith ---03/05/2019 04:32:39 PM---Hi 
Joan, I will be able to help later next week. If you coulGarren Smith 
---03/05/2019 04:32:39 PM---Hi Joan, I will be able to help later next 
week. If you could let me know of any


From: Garren Smith 
To: dev@couchdb.apache.org
Date: 03/05/2019 04:32 PM
Subject: Re: Sad state of Jenkins CI - please help fix our eunit tests!





Hi Joan,

I will be able to help later next week. If you could let me know of any
failing elixir tests I can start there.

Cheers
Garren

On Thu, May 2, 2019 at 10:48 PM Joan Touzet  wrote:

 > Hi everyone,
 >
 > Lately, our Jenkins CI runs on master (after merges) have been failing a
 > lot:
 >
 > https://s.apache.org/yuwY
 >
 > Just in the last run (#537), we have failures in eunit tests for
 > couch_mrview, mem3 and ddoc_cache that need active investigation. [1]
 >
 > Arguably, the reason no one is actively monitoring this and fixing the
 > tests is because Jenkins does not (yet) gate commits from landing on
 > master.
 >
 > This will change in the not-too-distant future. Travis CI has been
 > slower and slower as of late, and with ownership/leadership change of
 > Travis (the company) there's some trepidation in the community at large
 > about its long-term survivability as well.
 >
 > IBM has graciously committed to a targeted hardware donation for build
 > machines for our CI needs, to help us get runs done faster and in a
 > controlled environment. I'll be working with them once that machine
 > arrives to set up the new CI environment and ensure it does what we all
 > expect. If anyone has any input on what that should look like, do reply
 > to this email and let me know.
 >
 > Fixing Jenkins also will fix our broken snapshot package builds, which
 > very soon *will include ARM64 support* that the community has been
 > asking for, for a long time. Until we have regular greens on the board
 > for ARM64, I'm not willing to approve greenlighting public packages or a
 > Docker container for this platform. (Same goes for other platforms.)
 >
 >
 > In short: *PLEASE HELP FIX THE FAILING TESTS*. If you want a bug per
 > failing test, I can do that, let me know.
 >
 > -Joan "all green all the time?" Touzet
 >
 >
 > [1]: The failure in 537 on CentOS 7 comes from my recent image rebuild,
 > and CentOS's/EPEL's very recent decision to drop the python3 alias in
 > favour of version-specific ones (python3.4, python3.6). I'll add a
 > workaround for this via a /usr/local symlink in the image today.
 >
 >

Re: [osuosl-openpower] Projects not completing Survey

[Joan Touzet]

Hi Daniel,

Thanks so much for being on top of this!

CouchDB did indeed get a copy (via me) and I did respond/complete the
survey.

-Joan

On 2019-05-02 20:14, Daniel Pono Takamori wrote:
> Hey Lance,
> Big Top, CouchDB and Cassandra didn't see this original email won't be able
> to see this email, so I've added their lists so hopefully they can give
> some input :)
> As far as I can tell, only Cassandra uses the VMs setup against the
> standard Jenkins, so hopefully Big Top and CouchDB can appropriately
> respond to their use cases.
> 
> Thanks in advance everyone for filling out the form and feel free to ping
> me off list if there's anything you need from me.
> 
> On Wed, May 1, 2019 at 4:13 PM Lance Albertson  wrote:
> 
>> Below is a list of projects that have not completed their survey according
>> to our records. I will start powering down virtual machines on May 6th if
>> we do not have any response from your project. If you think your project
>> being listed is an error, please let me know. Feel free to fill out the
>> survey [1] in the meantime.
>>
>> Thank you!
>>
>> [1] https://forms.gle/ni22gW3y2iuT55vb9
>>
>> Anaconda
>> Apache Big Top
>> Apache Software Foundation / CouchDB
>> Apple Swift
>> Blockchain on Power
>> Blosc
>> checkpoint-restore
>> elephant-shed
>> envoy
>> Fedora
>> Firefox/Mozilla
>> GCC / Clang
>> Ginga middleware (ISDB-T)
>> Goy.Chat
>> Hadoop_Spark
>> Hortonworks Data Platform
>> IBM/OSU RCU project
>> ICU
>> istio on Power
>> java concurrency libraries
>> Jellyfish
>> juju-charms
>> Julia/LLVM
>> Jupyter/base-notebook
>> LAPACK
>> libjpeg-turbo
>> libpod
>> libvpx
>> Linux Kernal
>> LLVM
>> lock-free queue
>> Machine Learning/Deep Learning
>> Mesos
>> microbench
>> Multiple LLVM/HHVM/*
>> Node.js
>> nvidia-docker
>> Observationally Cooperative Multithreading
>> OCaml
>> ONNX
>> OpenBlas
>> opencv
>> OpenJDK
>> openlibm
>> OpenWhisk multi-architecture build
>> OrientDB
>> PDX Tickless Kernel
>> pgSphere
>> PostgreSQL
>> Presto
>> PyTorch
>> qiskit-sdk-py
>> SHA-3
>> snowpatch for OpenPOWER
>> SSSUP - Sant'Anna
>> Travis CI
>> VSXSIMD
>> WebM
>> x265 HEVC Encoder
>> Zarafa
>>
>> --
>> Lance Albertson
>> Director
>> Oregon State University | Open Source Lab
>> ___
>> openpower mailing list
>> openpo...@osuosl.org
>> https://lists.osuosl.org/mailman/listinfo/openpower
>>
> 

Re: [osuosl-openpower] Projects not completing Survey

[Joan Touzet]

Hi Daniel,

Thanks so much for being on top of this!

CouchDB did indeed get a copy (via me) and I did respond/complete the
survey.

-Joan

On 2019-05-02 20:14, Daniel Pono Takamori wrote:
> Hey Lance,
> Big Top, CouchDB and Cassandra didn't see this original email won't be able
> to see this email, so I've added their lists so hopefully they can give
> some input :)
> As far as I can tell, only Cassandra uses the VMs setup against the
> standard Jenkins, so hopefully Big Top and CouchDB can appropriately
> respond to their use cases.
> 
> Thanks in advance everyone for filling out the form and feel free to ping
> me off list if there's anything you need from me.
> 
> On Wed, May 1, 2019 at 4:13 PM Lance Albertson  wrote:
> 
>> Below is a list of projects that have not completed their survey according
>> to our records. I will start powering down virtual machines on May 6th if
>> we do not have any response from your project. If you think your project
>> being listed is an error, please let me know. Feel free to fill out the
>> survey [1] in the meantime.
>>
>> Thank you!
>>
>> [1] https://forms.gle/ni22gW3y2iuT55vb9
>>
>> Anaconda
>> Apache Big Top
>> Apache Software Foundation / CouchDB
>> Apple Swift
>> Blockchain on Power
>> Blosc
>> checkpoint-restore
>> elephant-shed
>> envoy
>> Fedora
>> Firefox/Mozilla
>> GCC / Clang
>> Ginga middleware (ISDB-T)
>> Goy.Chat
>> Hadoop_Spark
>> Hortonworks Data Platform
>> IBM/OSU RCU project
>> ICU
>> istio on Power
>> java concurrency libraries
>> Jellyfish
>> juju-charms
>> Julia/LLVM
>> Jupyter/base-notebook
>> LAPACK
>> libjpeg-turbo
>> libpod
>> libvpx
>> Linux Kernal
>> LLVM
>> lock-free queue
>> Machine Learning/Deep Learning
>> Mesos
>> microbench
>> Multiple LLVM/HHVM/*
>> Node.js
>> nvidia-docker
>> Observationally Cooperative Multithreading
>> OCaml
>> ONNX
>> OpenBlas
>> opencv
>> OpenJDK
>> openlibm
>> OpenWhisk multi-architecture build
>> OrientDB
>> PDX Tickless Kernel
>> pgSphere
>> PostgreSQL
>> Presto
>> PyTorch
>> qiskit-sdk-py
>> SHA-3
>> snowpatch for OpenPOWER
>> SSSUP - Sant'Anna
>> Travis CI
>> VSXSIMD
>> WebM
>> x265 HEVC Encoder
>> Zarafa
>>
>> --
>> Lance Albertson
>> Director
>> Oregon State University | Open Source Lab
>> ___
>> openpower mailing list
>> openpo...@osuosl.org
>> https://lists.osuosl.org/mailman/listinfo/openpower
>>
> 

Re: [osuosl-openpower] Projects not completing Survey

[Joan Touzet]

Hi Daniel,

Thanks so much for being on top of this!

CouchDB did indeed get a copy (via me) and I did respond/complete the
survey.

-Joan

On 2019-05-02 20:14, Daniel Pono Takamori wrote:
> Hey Lance,
> Big Top, CouchDB and Cassandra didn't see this original email won't be able
> to see this email, so I've added their lists so hopefully they can give
> some input :)
> As far as I can tell, only Cassandra uses the VMs setup against the
> standard Jenkins, so hopefully Big Top and CouchDB can appropriately
> respond to their use cases.
> 
> Thanks in advance everyone for filling out the form and feel free to ping
> me off list if there's anything you need from me.
> 
> On Wed, May 1, 2019 at 4:13 PM Lance Albertson  wrote:
> 
>> Below is a list of projects that have not completed their survey according
>> to our records. I will start powering down virtual machines on May 6th if
>> we do not have any response from your project. If you think your project
>> being listed is an error, please let me know. Feel free to fill out the
>> survey [1] in the meantime.
>>
>> Thank you!
>>
>> [1] https://forms.gle/ni22gW3y2iuT55vb9
>>
>> Anaconda
>> Apache Big Top
>> Apache Software Foundation / CouchDB
>> Apple Swift
>> Blockchain on Power
>> Blosc
>> checkpoint-restore
>> elephant-shed
>> envoy
>> Fedora
>> Firefox/Mozilla
>> GCC / Clang
>> Ginga middleware (ISDB-T)
>> Goy.Chat
>> Hadoop_Spark
>> Hortonworks Data Platform
>> IBM/OSU RCU project
>> ICU
>> istio on Power
>> java concurrency libraries
>> Jellyfish
>> juju-charms
>> Julia/LLVM
>> Jupyter/base-notebook
>> LAPACK
>> libjpeg-turbo
>> libpod
>> libvpx
>> Linux Kernal
>> LLVM
>> lock-free queue
>> Machine Learning/Deep Learning
>> Mesos
>> microbench
>> Multiple LLVM/HHVM/*
>> Node.js
>> nvidia-docker
>> Observationally Cooperative Multithreading
>> OCaml
>> ONNX
>> OpenBlas
>> opencv
>> OpenJDK
>> openlibm
>> OpenWhisk multi-architecture build
>> OrientDB
>> PDX Tickless Kernel
>> pgSphere
>> PostgreSQL
>> Presto
>> PyTorch
>> qiskit-sdk-py
>> SHA-3
>> snowpatch for OpenPOWER
>> SSSUP - Sant'Anna
>> Travis CI
>> VSXSIMD
>> WebM
>> x265 HEVC Encoder
>> Zarafa
>>
>> --
>> Lance Albertson
>> Director
>> Oregon State University | Open Source Lab
>> ___
>> openpower mailing list
>> openpo...@osuosl.org
>> https://lists.osuosl.org/mailman/listinfo/openpower
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Sad state of Jenkins CI - please help fix our eunit tests!

[Joan Touzet]

Hi everyone,

Lately, our Jenkins CI runs on master (after merges) have been failing a
lot:

https://s.apache.org/yuwY

Just in the last run (#537), we have failures in eunit tests for
couch_mrview, mem3 and ddoc_cache that need active investigation. [1]

Arguably, the reason no one is actively monitoring this and fixing the
tests is because Jenkins does not (yet) gate commits from landing on master.

This will change in the not-too-distant future. Travis CI has been
slower and slower as of late, and with ownership/leadership change of
Travis (the company) there's some trepidation in the community at large
about its long-term survivability as well.

IBM has graciously committed to a targeted hardware donation for build
machines for our CI needs, to help us get runs done faster and in a
controlled environment. I'll be working with them once that machine
arrives to set up the new CI environment and ensure it does what we all
expect. If anyone has any input on what that should look like, do reply
to this email and let me know.

Fixing Jenkins also will fix our broken snapshot package builds, which
very soon *will include ARM64 support* that the community has been
asking for, for a long time. Until we have regular greens on the board
for ARM64, I'm not willing to approve greenlighting public packages or a
Docker container for this platform. (Same goes for other platforms.)


In short: *PLEASE HELP FIX THE FAILING TESTS*. If you want a bug per
failing test, I can do that, let me know.

-Joan "all green all the time?" Touzet


[1]: The failure in 537 on CentOS 7 comes from my recent image rebuild,
and CentOS's/EPEL's very recent decision to drop the python3 alias in
favour of version-specific ones (python3.4, python3.6). I'll add a
workaround for this via a /usr/local symlink in the image today.

Re: Shards-directory still big after deleting big database in Fauxton

[Joan Touzet]

Look for a .deleted directory under your data/ directory. The files may 
not have been deleted but moved aside due to the 
enable_database_recovery setting, or because the DB was still in use 
when you restarted CouchDB.


Another useful command is:

$ du -sh /opt/couchdb/data/*

which should tell you where the storage is being used. Does this show 
anything useful to you?


-Joan

On 2019-05-01 2:22 p.m., Frank Walter wrote:

Hello

I have CouchDB v2.3.1 (on Ubuntu 14.04) and I use it only for creating
Wikipedia databases with mwscrape.
My shards folder was too big, over 50 GB big, so I deleted one big db
(frwiki) which had 32 GB in Fauxton. That db is gone now.
After this, I thought now my shards folder should be about 20 GB but it
is still 52 GB.

I don't find any documentation about that in the CouchDB Doc.
I restarted CouchDB (/etc/init.d/couchdb restart) but nothing changes.

How can I reduce the size of shards? How can I get rid of this ghost-db?

My next step would be, if I cannot solve this issue, to uninstall
CouchDB 2.x and reinstall 1.x, because I dont need that feature of
cluster server anyway. I see only inconvenience for my use.

Thanks

frank

Docker Hub security breach and CouchDB image update

[Joan Touzet]

Hello there,

You may have read about the recent breach of security at Docker Hub[1].

In light of this breach, and in the interest of security for all of our
users, today we have taken the following actions:

* Reset all passwords and tokens that were in use with Docker Hub.
  (Apache CouchDB never published anything to Docker Hub in an
  automated fashion, by policy.)

* Rebuilt and republished all currently supported CouchDB images in use:

  apache/couchdb:2.3.1 (aka "latest")
  apache/couchdb:2.3.0

* Rebuilt and republished these images, which are no longer supported:
  apache/couchdb:1.7.2
  apache/couchdb:1.7.2-couchperuser

* Removed all tags that are no longer supported or have known security
  issues. This includes versions 1.6.*, 1.7.1, 2.0.*, 2.1.*, and 2.2.*.

While there were no known issues with any of our published images, and
we were not notified that our password hash was potentially leaked, this
action was in the best interest of the project.

Note that the "official" Docker couchdb image (what you get if you run
`docker pull couchdb` instead of `docker pull apache/couchdb`) is
maintained by Docker staff, not us, and is auto-published using their
infrastructure based on the Dockerfile and scripts we provide. They are
already updating this image on a regular basis.

-Joan "Move over, Maersk" Touzet

[1]: https://success.docker.com/article/docker-hub-user-notification

Docker Hub security breach and CouchDB image update

[Joan Touzet]

Hello there,

You may have read about the recent breach of security at Docker Hub[1].

In light of this breach, and in the interest of security for all of our
users, today we have taken the following actions:

* Reset all passwords and tokens that were in use with Docker Hub.
  (Apache CouchDB never published anything to Docker Hub in an
  automated fashion, by policy.)

* Rebuilt and republished all currently supported CouchDB images in use:

  apache/couchdb:2.3.1 (aka "latest")
  apache/couchdb:2.3.0

* Rebuilt and republished these images, which are no longer supported:
  apache/couchdb:1.7.2
  apache/couchdb:1.7.2-couchperuser

* Removed all tags that are no longer supported or have known security
  issues. This includes versions 1.6.*, 1.7.1, 2.0.*, 2.1.*, and 2.2.*.

While there were no known issues with any of our published images, and
we were not notified that our password hash was potentially leaked, this
action was in the best interest of the project.

Note that the "official" Docker couchdb image (what you get if you run
`docker pull couchdb` instead of `docker pull apache/couchdb`) is
maintained by Docker staff, not us, and is auto-published using their
infrastructure based on the Dockerfile and scripts we provide. They are
already updating this image on a regular basis.

-Joan "Move over, Maersk" Touzet

[1]: https://success.docker.com/article/docker-hub-user-notification

Re: [DISCUSS] Improve load shedding by enforcing timeouts throughout stack

[Joan Touzet]

 

wrote:



503 imo.

--
Robert Samuel Newson
rnew...@apache.org

On Thu, 18 Apr 2019, at 18:24, Adam Kocoloski wrote:

Yes, we should. Currently it’s a 500, maybe there’s something more

appropriate:








https://github.com/apache/couchdb/blob/8ef42f7241f8788afc1b6e7255ce78ce5d5ea5c3/src/chttpd/src/chttpd.erl#L947-L949


Adam


On Apr 18, 2019, at 12:50 PM, Joan Touzet 

wrote:


What happens when it turns out the client *hasn't* timed out and

we

just...hang up on them? Should we consider at least trying to send

back

some sort of HTTP status code?

-Joan

On 2019-04-18 10:58, Garren Smith wrote:

I'm +1 on this. With partition queries, we added a few more

timeouts

that

can be enabled which Cloudant enable. So having the ability to

shed

old

requests when these timeouts get hit would be great.

Cheers
Garren

On Tue, Apr 16, 2019 at 2:41 AM Adam Kocoloski <

kocol...@apache.org>

wrote:



Hi all,

For once, I’m coming to you with a topic that is not strictly

about

FoundationDB :)

CouchDB offers a few config settings (some of them

undocumented) to

put a

limit on how long the server is allowed to take to generate a

response. The

trouble with many of these timeouts is that, when they fire,

they do

not

actually clean up all of the work that they initiated. A couple

of

examples:


- Each HTTP response coordinated by the “fabric” application

spawns

several ephemeral processes via “rexi" on different nodes in the

cluster to

retrieve data and send it back to the process coordinating the

response. If

the request timeout fires, the coordinating process will be

killed

off, but

the ephemeral workers might not be. In a healthy cluster they’ll

exit on

their own when they finish their jobs, but there are conditions

under which

they can sit around for extended periods of time waiting for an

overloaded

gen_server (e.g. couch_server) to respond.

- Those named gen_servers (like couch_server) responsible for

serializing

access to important data structures will dutifully process

messages

received from old requests without any regard for (of even

knowledge

of)

the fact that the client that sent the message timed out long

ago.

This can

lead to a sort of death spiral in which the gen_server is

ultimately

spending ~all of its time serving dead clients and every client

is

timing

out.

I’d like to see us introduce a documented maximum request

duration

for all

requests except the _changes feed, and then use that

information to

aid in

load shedding throughout the stack. We can audit the codebase

for

gen_server calls with long timeouts (I know of a few on the

critical

path

that set their timeouts to `infinity`) and we can design servers

that

efficiently drop old requests, knowing that the client who made

the

request

must have timed out. A couple of topics for discussion:

- the “gen_server that sheds old requests” is a very generic

pattern, one

that seems like it could be well-suited to its own behaviour. A

cursory

search of the internet didn’t turn up any prior art here, which

surprises

me a bit. I’m wondering if this is worth bringing up with the

broader

Erlang community.

- setting and enforcing timeouts is a healthy pattern for

read-only

requests as it gives a lot more feedback to clients about the

health

of the

server. When it comes to updates things are a little bit more

muddy,

just

because there remains a chance that an update can be committed,

but

the

caller times out before learning of the successful commit. We

should

try to

minimize the likelihood of that occurring.

Cheers, Adam

P.S. I did say that this wasn’t _strictly_ about FoundationDB,

but

of

course FDB has a hard 5 second limit on all transactions, so it

is a

bit of

a forcing function :).Even putting FoundationDB aside, I would

still

argue

to pursue this path based on our Ops experience with the current

codebase.

[jira] [Resolved] (WHIMSY-247) Persist changed initials for report comments

[Joan Touzet (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WHIMSY-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joan Touzet resolved WHIMSY-247.

Resolution: Fixed

I think this is fixed now; will reopen if not.

> Persist changed initials for report comments
> 
>
> Key: WHIMSY-247
> URL: https://issues.apache.org/jira/browse/WHIMSY-247
> Project: Whimsy
>  Issue Type: Task
>  Components: Website
>    Reporter: Joan Touzet
>Priority: Minor
>
> Right now, when adding a comment as a board member in the tool, I can 
> customise my initials when leaving a comment. I like doing this - more people 
> know me as "wohali" than "jt," and when I personally use my initials, I use 
> "jst" not "jt."
> The tool could simply see that the field has changed, and persist that 
> abbreviation for the future when initials are called for. If no customisation 
> has been made, use the person's initials from the current source.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] Welcome Paul Berschick as Committer

[Joan Touzet]

Hi Paul - congratulations, and thank you for all your hard work!

On 2019-04-23 7:19, Myrle Krantz wrote:
> Hey all,
> 
> Please welcome Paul Berschick as a committer for community development.  He
> helped us put together the Apache Roadshow in Berlin last year, doing
> everything from booking the venue to organizing the video to  communicating
> with the printer to get the right colors on the Apache feather on the
> conference t-shirt.
> 
> This year he's helping us put together ApacheCon in Berliln.
> 
> Thank you for everything you've done Paul, and we look forward to
> continuing to work with you!
> 
> Best Regards,
> Myrle
> 


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

Re: [ANNOUNCE] Welcome Gris Cuevas as new PMC member

[Joan Touzet]

Welcome, Gris! I don't need to expect great things, because they've
already happened.

-Joan

On 2019-04-23 7:26, Myrle Krantz wrote:
> Hey all,
> 
> Please welcome Gris Cuevas as the newest member of the Community
> Development PMC.
> 
> Gris is helping out representing Apache at various conferences and helping
> to make our own conferences a success.  Gris has also offered to help us
> with Diversity & Inclusion work and has already made several constructive,
> concrete proposals.  She's helping us find the way forward through a
> particularly messy and difficult topic.
> 
> Thank you Gris, for accepting our invitation to continue your awesome work
> together with us!  I look forward to continuing to work together with you!
> 
> Best Regards,
> Myrle Krantz
> PMC Member, Apache Community Development
> 


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

Re: [DISCUSS] Improve load shedding by enforcing timeouts throughout stack

[Joan Touzet]

What happens when it turns out the client *hasn't* timed out and we
just...hang up on them? Should we consider at least trying to send back
some sort of HTTP status code?

-Joan

On 2019-04-18 10:58, Garren Smith wrote:
> I'm +1 on this. With partition queries, we added a few more timeouts that
> can be enabled which Cloudant enable. So having the ability to shed old
> requests when these timeouts get hit would be great.
> 
> Cheers
> Garren
> 
> On Tue, Apr 16, 2019 at 2:41 AM Adam Kocoloski  wrote:
> 
>> Hi all,
>>
>> For once, I’m coming to you with a topic that is not strictly about
>> FoundationDB :)
>>
>> CouchDB offers a few config settings (some of them undocumented) to put a
>> limit on how long the server is allowed to take to generate a response. The
>> trouble with many of these timeouts is that, when they fire, they do not
>> actually clean up all of the work that they initiated. A couple of examples:
>>
>> - Each HTTP response coordinated by the “fabric” application spawns
>> several ephemeral processes via “rexi" on different nodes in the cluster to
>> retrieve data and send it back to the process coordinating the response. If
>> the request timeout fires, the coordinating process will be killed off, but
>> the ephemeral workers might not be. In a healthy cluster they’ll exit on
>> their own when they finish their jobs, but there are conditions under which
>> they can sit around for extended periods of time waiting for an overloaded
>> gen_server (e.g. couch_server) to respond.
>>
>> - Those named gen_servers (like couch_server) responsible for serializing
>> access to important data structures will dutifully process messages
>> received from old requests without any regard for (of even knowledge of)
>> the fact that the client that sent the message timed out long ago. This can
>> lead to a sort of death spiral in which the gen_server is ultimately
>> spending ~all of its time serving dead clients and every client is timing
>> out.
>>
>> I’d like to see us introduce a documented maximum request duration for all
>> requests except the _changes feed, and then use that information to aid in
>> load shedding throughout the stack. We can audit the codebase for
>> gen_server calls with long timeouts (I know of a few on the critical path
>> that set their timeouts to `infinity`) and we can design servers that
>> efficiently drop old requests, knowing that the client who made the request
>> must have timed out. A couple of topics for discussion:
>>
>> - the “gen_server that sheds old requests” is a very generic pattern, one
>> that seems like it could be well-suited to its own behaviour. A cursory
>> search of the internet didn’t turn up any prior art here, which surprises
>> me a bit. I’m wondering if this is worth bringing up with the broader
>> Erlang community.
>>
>> - setting and enforcing timeouts is a healthy pattern for read-only
>> requests as it gives a lot more feedback to clients about the health of the
>> server. When it comes to updates things are a little bit more muddy, just
>> because there remains a chance that an update can be committed, but the
>> caller times out before learning of the successful commit. We should try to
>> minimize the likelihood of that occurring.
>>
>> Cheers, Adam
>>
>> P.S. I did say that this wasn’t _strictly_ about FoundationDB, but of
>> course FDB has a hard 5 second limit on all transactions, so it is a bit of
>> a forcing function :).Even putting FoundationDB aside, I would still argue
>> to pursue this path based on our Ops experience with the current codebase.
> 

Re: [Discuss] Attributing contributions to commercial vendors investing in projects

[Joan Touzet]

On 2019-04-17 9:04 p.m., Griselda Cuevas wrote:

I want to understand how we
see and value the topic since I consider it an important influencer in the
D&I topic. More clearly - some projects are not diverse on the commercial
vendor affiliation dimension, which can create an environment not so
friendly for diverse voices to exists so worth exploring this potential
root cause. I need time to elaborate on this hypothesis since it might help
articulate a better question.


I 100% agree, without naming names. Holding back committership from 
people who may not have the same ideas as you, giving them "limited 
committership" privileges (effectively no different that 'contributor' 
status), or simply ignoring those contributions can "other" many -- all 
of this can be wielded poorly by corporations intent on ensuring their 
own commercial interests in an Apache project are not subverted.


I just don't want to lose sight of what the ASF has managed to achieve 
over its existence, namely setting the bar for supportive, collaborative 
cooperation between volunteers and corporations in the open source 
realm, in the interest of the public good. Finding a way to acknowledge, 
at the project level, specific corporate involvement and commitment as 
good development partners without lionizing or deifying them in the eyes 
of the general public or the project's user base is critical.



Thank you!


And thank you for raising something that I've been too nervous to bring 
up on my own.


-Joan

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

Re: [Discuss] Attributing contributions to commercial vendors investing in projects

[Joan Touzet]

Sorry for the self-reply, this sentence:

On 2019-04-17 18:04, Joan Touzet wrote:
> The danger in writing it down is that it will change people's
> opinions of .

should read:

> the situation by implying the corporate relationship itself is what
> is driving the decision making, when that may not be true at all.

-Joan


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

Re: [Discuss] Attributing contributions to commercial vendors investing in projects

[Joan Touzet]

Sorry for the self-reply, this sentence:

On 2019-04-17 18:04, Joan Touzet wrote:
> The danger in writing it down is that it will change people's
> opinions of .

should read:

> the situation by implying the corporate relationship itself is what
> is driving the decision making, when that may not be true at all.

-Joan


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

Re: [Discuss] Attributing contributions to commercial vendors investing in projects

[Joan Touzet]

I'm generally in agreement with Rich, Jim, Shane, Sam and the other
"grey beards" who have responded on this thread already. We recognize
the individual, not the company, and the individual gets the merit.

That said, there are always rumours and scuttlebutt floating around of
this sort: "If company Q wasn't supporting Project X, Project X would
have died by now." Or: "Company J went out of business, so Project F is
basically abandoned." While industry insiders and project members
themselves are largely aware of these special situations, others outside
of the community may not be.

Gris, this is the flip-side of what you are proposing: making this
implicit knowledge more explicit. The danger in writing it down is that
it will change people's opinions of . By making these (sometimes
intentionally) nebulous relationships more concrete by putting them on
project home pages, you will necessarily impact how the project is
perceived, likely reducing its autonomy. Do we want to do this? I think
perhaps not.

One thing that's occurred to me in the past is: wouldn't it be nice to
know exactly who everyone on a given PMC works for, in the event of
"blocs" of voters banding together smelling fishy in terms of project
independence?

Then, on [5], I read this:

> Apache projects are run solely by their PMCs, as projects independent
> of outside corporations or organizations. It is important to maintain
> both the actual independence of our PMCs from third parties, as well
> as to ensure that PMCs are clearly seen to be run as independent
> projects, free of any controlling, exclusive, or otherwise
> exclusionary relationships with third parties or outside
> corporations.

So again we have the problem of "writing it down may make it seem truer
than it really is," and creating the perception of people not knowing
how to take off their Corp hat and put on their PMC hat. We have to
balance this against the need for projects to have the assurances that
their PMC is acting neutrally. Right now, I think the only escalation
path is for the project to go to the Board if they feel the PMC is
railroading a project away from its best interests...and I'm still not
sure that doesn't put an unnecessarily high barrier in those
contributors' way.

But I digress.



On 2019-04-17 16:54, Dinesh Joshi wrote:
> Some employers actually employ people from the community to work on
> Open Source projects. They should also be recognized.

And (I believe, see the next paragraph!) those companies are more than
welcome to put up a page (on their own websites) saying that they are
privileged to have, on their payroll, distinguished individuals who are
recognized as contributors, committers, PMC members and ASF members
within their ranks. This would show the company's commitment to the
individuals involved, which I think is a key point I'm taking away from
this discussion.

Shane: I couldn't tell from the marks linking page[5] whether or not
this would be acceptable, since my suggestion is precisely the reverse
of what is outlined there.

> Regardless, I have a different view on this. It would be a nice for
> individuals to fill in their professional affiliations to help others
> connect with their peers in their organizations. Perhaps this could
> be displayed in the people directory? It is along the lines of
> allowing individuals to declare their location which ASF already
> allows[1]
FOAF files can certainly include that information, in the Organization
or workplaceHomepage fields, though these would be supplementary to also
including Apache in those same fields. I believe FOAF allows for
multiples of these two classes, but I didn't read the spec in detail[2].

The question is whether or not we willfully disclose this information.
Currently it's not on our list of things we disclose on ASF websites[4],
and I'd be nervous about doing this across our entire base of committers
without explicit assent by ComDev and maybe Legal.

Another option is the 3rd party GitHub service, where you can show your
corporate affiliation via the organisations you participate in. Not
every company has a GitHub Org, but I'd be lying if I said I didn't
browse thru frequent contributors to Apache projects there and look to
see if I could see who employs those people.

An ancillary question would be whether or not it's time to move from the
largely abandoned FOAF format to the schema.org Person format instead,
possibly in JSON-LD format [3]. This is a tangent and if we want to
discuss this let's do so in a new thread.

> [1] http://community.zones.apache.org/map.html
[2]: http://xmlns.com/foaf/spec/
[3]: https://schema.org/Person
[4]: https://home.apache.org/foaf/index.html
[5]: https://www.apache.org/foundation/marks/linking


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

Re: Areas where we want to measure diversity, equity & inclusion

[Joan Touzet]

On 2019-04-14 3:03 p.m., dinesh.jo...@yahoo.com.INVALID wrote:

I would like to suggest another approach at measuring the funnel. I don't know 
whether this is feasible either but its just an idea that I'd love some feedback 
on. Most Apache projects seem to be using Jira. Contributors, Committers, PMC & 
Members are typically are on Jira. I think code as well as non-code tasks should be 
tracked on Jira boards.


Most, but not all - and, critically, the projects that are the most 
tapped into communities *outside* of the ASF are using GitHub issues and 
have dropped JIRA entirely. Ignoring these will ignore a statistically 
important part of our potential contributors. (I don't like the word 
"funnel" here, it sounds too sales-y.)



A potential solution to gather data would be to add a few optional biographical 
fields that Jira users can fill out. We can also show a one time call to action 
screen when they next login. The user should be able to easily dismiss it if 
they don't want to participate. This approach doesn't burden the PMC and we 
would have a better shot at getting data automatically. It also doesn't spam 
anyone's emails.
A slight variation of this idea is to not add any biographical fields to Jira, 
instead the screen directs the users to fill out the survey. However, I think 
adding the Biographical fields is better in the longterm as we will collect 
this data automatically as new people sign up in the Jira.
Finally, this is just an idea, I am not sure about its feasibility with respect 
to the Foundation's policies and legal requirements. But if we think this is a 
good idea, we can figure out answers to those questions as a follow up.
Thoughts?
Thanks,
Dinesh

 On Sunday, April 14, 2019, 3:12:38 AM PDT, Sam Ruby 
 wrote:
  
  On Sun, Apr 14, 2019 at 1:05 AM Griselda Cuevas  wrote:


Dinesh proposed we measure diversity in the project growth funnel [1].

Here's an initial list of what stages in the funnel we could measure:
- Potential committers
- Committers
- PMCs


Add ASF Members?


- Board

Other areas outside the funnel:
- Non-code committers
- Community builders
- Advocates

Let's keep adding.

[1]
https://lists.apache.org/thread.html/049ad49c0e2f1e704a53f83953886506c304bbcca7c2cae54b8cbd67@%3Cdiversity.apache.org%3E


- Sam Ruby

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

   



-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Revamping the ASF Committer Diversity Survey

[Joan Touzet]

On 2019-04-13 2:37 a.m., Dinesh Joshi wrote:

Rich, Myrle – both of you made great points. I especially think non-code
contributions are critical and generally go unrecognized. They are
equally as important.

Regarding gathering data about individuals being nominated, perhaps
sending a survey to the PMC Chairs to gather the stats, would that be
reasonable? I am just trying brainstorm an effective way to gather data
around who is being left out and associated reasons.



Hi Dinesh,

I like the idea, but the devil is in the details.

PMCs tend to be overloaded with responsibilities already. Unless we 
provide them something well-packaged and easy to run, we won't get any 
data this way.


You'll also end up with serious selection bias; we'll hear back from the 
PMCs who are motivated to tell us about specific people, or who are 
idle, or who have smaller communities (because it's easy to get your 
hands around who all there is).


I'm not saying this isn't doable, but I am having a hard time thinking 
of a way that we can get a good sample this way.


-Joan



Dinesh


On Apr 12, 2019, at 6:22 AM, Myrle Krantz  wrote:

On Thu, Apr 11, 2019 at 3:32 PM Rich Bowen  wrote:


Your suggestion of surveying non-committer Github contributors certainly
has merit, but, having tried to gather that kind of data in the past
(ie, actual contact info for contributors to an open source project,
based on Github names), it's not particularly easy, as even the people
that list their email address on Github (which is not everyone, by a
long shot) consider it pretty spammy to receive surveys.



Also, focusing on github contributions would leave out people who provide
customer support.  And documentation and graphics might not compare
appropriately in size with code contributions either.  But non-code
contributors is one of our biggest problem-areas IMHO.

Best,
Myrle



-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org



-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: Feature request: Git/GH Issues in reporter.apache.org ?

[Joan Touzet]

Hi Sebastian,

> From: "sebb" 
> > I believe reporter only currently pulls down commit statistics
> > from svn,
> 
> Does it? Where is that presented?.

My mistake! I saw the commits@ mailing lists and realized that this
only shows what got sent to the mailing list. It's a stand-in for
now at best, especially since with GitHub that can include
discussion on pull requests, issues, etc. and doesn't necessarily
represent commits to the repo.

"Dave Fisher"  wrote:
> The git commit data is available, but it is not in the tool. Have
> a look at https://gitbox.apache.org/repositories.json

Neat, but I'm only seeing total commits; this would need to be
recorded and diffed for the time periods useful to a PMC report.
It also doesn't automatically sum up all repos for a given PMC.

In reporter.a.o, it'd be lovely to see a summary line like:

  X commits by Y committers across Z Git repos and Q svn repos
  since -MM-DD.

-Joan "github and subversion and bears, oh my!" Touzet

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

Feature request: Git/GH Issues in reporter.apache.org ?

[Joan Touzet]

Hi everyone,

As a newly-elected board member, I'm discovering a blind spot
in the reporter.apache.org tool, specifically for projects that
have transitioned to git for version control and GitHub issues
for issue management.

I believe reporter only currently pulls down commit statistics
from svn, and issue data from JIRA. This makes it hard to know
whether a project is making active progress in drawing down
their ticket backlog or how active their repositor(y|ies) are.

Apparently, the code is in Python and here:

https://svn.apache.org/repos/asf/comdev/reporter.apache.org/trunk

and patches are welcome (TM), but I don't have the energy to
work on this myself.

Is anyone able to team up with Daniel Gruno to help add this
functionality to reporter?

-Joan "more metrics" Touzet

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

[jira] [Commented] (WHIMSY-247) Persist changed initials for report comments

[Joan Touzet (JIRA)]

[ 
https://issues.apache.org/jira/browse/WHIMSY-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813596#comment-16813596
 ] 

Joan Touzet commented on WHIMSY-247:


OK! This is good news. And I noticed when I went to make a comment yesterday on 
the fake board meeting tomorrow, indeed my initials as "wohali" persisted.

I *didn't* see them persist last week when I was queueing up comments and 
hadn't yet committed them. Does the change only take effect on a commit action?

> Persist changed initials for report comments
> 
>
> Key: WHIMSY-247
> URL: https://issues.apache.org/jira/browse/WHIMSY-247
> Project: Whimsy
>  Issue Type: Task
>  Components: Website
>Reporter: Joan Touzet
>Priority: Minor
>
> Right now, when adding a comment as a board member in the tool, I can 
> customise my initials when leaving a comment. I like doing this - more people 
> know me as "wohali" than "jt," and when I personally use my initials, I use 
> "jst" not "jt."
> The tool could simply see that the field has changed, and persist that 
> abbreviation for the future when initials are called for. If no customisation 
> has been made, use the person's initials from the current source.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (WHIMSY-247) Persist changed initials for report comments

[Joan Touzet (JIRA)]

Joan Touzet created WHIMSY-247:
--

 Summary: Persist changed initials for report comments
 Key: WHIMSY-247
 URL: https://issues.apache.org/jira/browse/WHIMSY-247
 Project: Whimsy
  Issue Type: Task
  Components: Website
Reporter: Joan Touzet


Right now, when adding a comment as a board member in the tool, I can customise 
my initials when leaving a comment. I like doing this - more people know me as 
"wohali" than "jt," and when I personally use my initials, I use "jst" not "jt."

The tool could simply see that the field has changed, and persist that 
abbreviation for the future when initials are called for. If no customisation 
has been made, use the person's initials from the current source.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: ApacheCon North America

[Joan Touzet]

"Patricia Shanahan"  wrote:
> On 4/7/2019 10:40 AM, Rich Bowen wrote:
> > On Fri, Apr 5, 2019, 22:40 Gris Cuevas  wrote:
> >> @Rich - would it be worth creating a D&I track and announce it
> >> broadly? My
> >> rationale is that by creating a formal talk we could incentivize
> >> folks to
> >> create content on the topic. I believe the Chicago Roadshow will
> >> have one
> >> so we could emulate. If this is the case, we could finish the
> >> track with a
> >> round table or workshop to construct an action plan for 1 or 2
> >> concrete
> >> deliverables. I'm happy to facilitate this.
> > I would ask that you coordinate with Sharan. She is running a
> > community
> > track. I know that they're not exactly the same thing but there is
> > substantial overlap. I just want to make sure that we are not
> > working at
> > cross-purposes.
> 
> I am not sure what mix we should have between talks in the community
> track and separate D&I talks. The community track will have wider
> visibility. A D&I track is likely to only attract people who already
> believe D&I is a valid issue calling for action.

Given this would be year 1 for a D&I track, and ApacheCon has typically
not focused on making this a thing, let alone ensuring people can
attend who can speak to the topic, I personally feel a full track is
premature.


> There seem to me to be two types of talks that may be offered. Talks
> that assume D&I is important, and address what to do about it on that
> assumption, would be more suitable for a D&I track or BoF. Talks that
> look at why we need to do something, or that discuss how D&I fits
> into
> general community issues are more suitable for the community track.

Compromise: If Sharan has room, carve out a half-day from the
community track for D&I. This could serve both the topics you mention
above without forcing a distinction, and would serve both groups of
interested parties. It'd also encourage cross-pollination vs. forcing
attendees to decide which track they'd rather attend (to the detriment
of both...)

Combine this with a BoF session for people who want to drive D&I
initiatives and we wouldn't be overreaching for Year One.

-Joan "I try not to bite off more than I can chew" Touzet

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: ApacheCon North America

[Joan Touzet]

Hi Patricia,

> Are there likely to be enough attendees who are on this mailing list
> to
> hold some sort of get together at ApacheCon North America? It is in
> Las
> Vegas, September 9-12, 2019.

As a new board member, I expect I'll be in attendance.

-Joan "wee, more travel" Touzet

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: ASF Application for Google Season of Docs 2019

[Joan Touzet]

Hi Maxim,

> From: "Maxim Solodovnik" 
> To: dev@community.apache.org, "Joan Touzet" 
> Sent: Thursday, April 4, 2019 12:03:39 PM
> Subject: Re: ASF Application for Google Season of Docs 2019
> 
> If we (as the ASF) will participate in GSoD
> We need to create idea list

Yup! I agree. I am stepping back to let others drive this directly.
It needs to be specific materials, and I don't have the time to drive
this discussion right now. If others don't, then this can die
here.

> And if some ASF project will participate as part of ASF it can be NOT
> selected
> So we can wisely choose our best GSoD ideas

No, this is not what we heard back from Google. Here's the quote:

> “I believe the ASF has already applied. However, we are not setup to handle 
> multiple applications through an umbrella organization, so yes, you may want 
> to have Apache Cassandra apply separately.”

So the ASF and ASF projects can both apply, and be considered
equally. If 5 projects want to apply, ASF would be the 6th 
"project." Sure, we're limited by how many tech writers GSOD brings
in, but that's not really our problem. Having more projects should
statistically increase the chances that more ASF projects overall
get writers.

-Joan "more tech writers!" Touzet

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

Re: ASF Application for Google Season of Docs 2019

[Joan Touzet]

> From: "Maxim Solodovnik" 
> To: dev@community.apache.org
> Sent: Thursday, April 4, 2019 11:20:55 AM
> Subject: Re: ASF Application for Google Season of Docs 2019
> 
> Hello Adina,
> 
> This make sense
> 
> But these 1 or 2 tech writers will select from project ideas
> They can't just write documentation for the whole ASF/Incubator
> 
> I still can act as backup admin for GSoD :)

Hi Maxim,

On the contrary, what Gris, Betrand and I are saying is that 
the Incubator and the overarching ASF have a lot of assets that
need redesign and rework. This isn't about our public-facing
website assets, but for things that the Foundation writes and
maintains for the benefit of all projects. The Incubator is
one. Gris brings up the "meritocracy" angle, that's another.
There's a bunch of Infra writing that could do with improvement,
too.

The thing we need to be careful about here is that these are
*tech* writers, so we need to bring proposals that are more
technically oriented. Some of the pending work may not fit
into that area as well, though I don't know what the over-arching
goals of GSOD are.

-Joan "writing is fundamental" Touzet


> On Thu, 4 Apr 2019 at 20:50, Adina Crainiceanu 
> wrote:
> >
> > Hi,
> >
> > Can we discuss whether ASF should apply as organization a little
> > more? The
> > answer Dinesh got did not seem to preclude ASF and individual
> > Apache
> > projects all applying as separate organizations. This year, when
> > GSOD is
> > new, each organization gets at most 2 spots. In future years, the
> > number of
> > spots might depend on the number of projects proposed by an
> > organization
> > and PAST SUCCESS in the program. I believe that is the case for
> > GSOC, where
> > new organizations get at most  1-2 spots, but "veteran"
> > organizations get
> > more spots. If ASF does not apply this year, but the program
> > expands and
> > ASF would like to apply in future years, ASF will likely be
> > considered a
> > "new" organization whenever it applies first as ASF and will likely
> > get
> > only a few spots the first time. So it would make sense to apply
> > this year.
> >
> > In Apache Rya(incubating) we are interested to propose some work
> > under the
> > ASF application and I'm happy to help with the application.
> >
> > Best,
> > Adina
> >
> >
> > On Thu, Apr 4, 2019 at 6:02 AM Bertrand Delacretaz
> > 
> > wrote:
> >
> > > Hi,
> > >
> > > On Wed, Apr 3, 2019 at 10:38 PM Griselda Cuevas
> > > 
> > > wrote:
> > > > ...If I'm not mistaken, this could fall under what Joan,
> > > > Bertrand and
> > > Rich
> > > > were already doing, so perhaps they could help as mentors? ...
> > >
> > > I'm happy to help as a mentor, especially as far as the Incubator
> > > is
> > > concerned - I've been working on
> > > http://incubator.apache.org/cookbook/
> > > recently and getting help on that and on a general simplification
> > > and
> > > cleanup of the Incubator website would be fantastic.
> > >
> > > Gris, shall we apply for the Incubator as one specific topic or
> > > do you
> > > want to make a more general application?
> > >
> > > -Bertrand
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> > >
> >
> > --
> 
> 
> 
> --
> WBR
> Maxim aka solomax
> 
> -
> 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

Re: [DISCUSS] Per-doc access control

[Joan Touzet]

One parenthetical...

> From: "Adam Kocoloski" 
> 
> On a somewhat-related note, I have had conversations before with
> folks who are keen to adopt these sorts of fine-grained access
> control systems who said they actually prefer to have a 403
> Forbidden response list the set of privileges that would be
> sufficient to access the resource. I found this surprising, but I
> guess it comes down to a user needing to figure out what kind of
> security exception to apply for in order to make progress with some
> data analysis. I think this is a topic on which we could make a
> fairly late-binding decision — or even have it as a configurable
> option.

Anyone who's ever had to deal with Amazon's AWS IAM configuration
certainly can appreciate this need. I'm +1 on the idea, assuming it's
not hard to implement...but...

The problem is that it can be a data leak. In Jan's initial gist, he
shows the _access field being populated by usernames only (Scenario 1).
The only possible exception here is to get your username added to the
_access field on that document.

If we do this via roles, then you could be leaking role name
definitions via this response. Not sure we care, but having a full
list of roles that could possibly provide that permission is certainly
a hole.

If we do this via _capability_, then you're looking at a set of
permissions such as reader, writer, deleter, and that specific
permission could be returned:

  {"needed":"writer", "obtained":"reader"}

That'd work, but it's different from what Jan has proposed to date, I
believe, especially in distinguishing between read, write, and delete.

-Joan

Re: ASF Application for Google Season of Docs 2019

[Joan Touzet]

Sharan, might want to keep the ASF application if we want their help
with tech doc writing for things like the incubator, infra, etc. and
other internally-facing ASF stuff. Not sure it makes sense for those
groups to be individually reaching out on those topics.

-Joan

- Original Message -
> From: "Sharan Foga" 
> To: dev@community.apache.org
> Sent: Wednesday, April 3, 2019 3:52:13 PM
> Subject: Re: ASF Application for Google Season of Docs 2019
> 
> Agreed.
> 
> I'll ask them to delete the ASF application for Season of Docs and
> each Apache project can apply for themselves. I'll check the email
> thread for those projects interested and send a message to their dev
> list.
> 
> Thanks
> Sharan
> 
> On 2019/04/03 15:29:59, Maxim Solodovnik 
> wrote:
> > In such case I see no need in ASF wide org admins 
> > "it's every man for himself." (c)
> > 
> > On Wed, 3 Apr 2019 at 22:24, Dinesh Joshi
> >  wrote:
> > >
> > > I heard back. Here’s the exact response -
> > >
> > > “I believe the ASF has already applied. However, we are not setup
> > > to handle multiple applications through an umbrella
> > > organization, so yes, you may want to have Apache Cassandra
> > > apply separately.”
> > >
> > > Thanks,
> > >
> > > Dinesh
> > >
> > > > On Apr 2, 2019, at 10:39 PM, Sharan Foga 
> > > > wrote:
> > > >
> > > > That's great Dinesh.
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > >> On 2019/04/03 05:35:25, Dinesh Joshi
> > > >>  wrote:
> > > >> I have reached out to them seeking clarification. Will let you
> > > >> all know when I hear back.
> > > >>
> > > >> Dinesh
> > > >>
> > > >>> On Apr 2, 2019, at 10:33 PM, Sharan Foga 
> > > >>> wrote:
> > > >>>
> > > >>> Hi Aizhamal
> > > >>>
> > > >>> The rules are that a maximum of 2 technical writers will be
> > > >>> allocated per organisation - and we are asking for the
> > > >>> maximum. This is a Google constraint not ours. And even
> > > >>> though we have asked for 2, if accepted there is also the
> > > >>> possibility that we get allocated only 1.
> > > >>>
> > > >>> My thought is that unlike GSoC where there are lots of
> > > >>> students wanting to apply and participate, there is only a
> > > >>> limited number of technical writers available so to ensure
> > > >>> accepted organisations get at least one writer - it is being
> > > >>> limited.
> > > >>>
> > > >>> Thanks
> > > >>> Sharan
> > > >>>
> > >  On 2019/04/02 21:57:20, Aizhamal Nurmamat kyzy
> > >   wrote:
> > >  Hi Sharan,
> > > 
> > >  We plan to prepare ideas list for at least 2 Apache
> > >  projects, in particular
> > >  for Airflow, Beam and possibly Spark. I am sure there are
> > >  other projects
> > >  that would like to participate, therefore I’m wondering
> > >  whether 2 tech
> > >  writers will be enough? Can we ask for more?
> > > 
> > >  I’m happy to chat further to figure out what’s the best
> > >  course of action.
> > > 
> > >  Thanks,
> > >  Aizhamal
> > > 
> > > 
> > > > On Tue, Apr 2, 2019 at 14:03 Sharan Foga
> > > >  wrote:
> > > >
> > > > Hi All
> > > >
> > > > As mentioned the applications for the Google Season of Docs
> > > > opened today
> > > > and I'm working my way through it on behalf of the ASF.
> > > >
> > > > If accepted, we will be allocated either one or two
> > > > techical writers.
> > > > Google will also pay the ASF a stipend of $500 per
> > > > technical writer
> > > > mentored (which I hope can go directly to fundraising :-)
> > > >
> > > > Each project that wants to participate must provide two
> > > > mentors for each
> > > > documentation project.
> > > >
> > > > As part of the application process there are a few things
> > > > that we need to
> > > > setup.
> > > >
> > > > 1. Season of Docs Page and List of Project Ideas
> > > > We need to create a public webpage about Season of Docs
> > > > that contains the
> > > > list of project ideas for documentation. I have created a
> > > > page on the
> > > > ComDev wiki https://s.apache.org/w4CH  with a table for
> > > > projects to
> > > > record their ideas.
> > > >
> > > > 2. Alternative administrator.
> > > > I’ve set myself up as the primary admin and Maxim as the
> > > > alternative admin
> > > > (Maxim, I need to confirm your contact email and you will
> > > > also need to
> > > > register as the alternative admin and I will email you the
> > > > link offline)
> > > >
> > > > 3. Mentors
> > > > All mentors from the projects interested in participating
> > > > must register
> > > > individually at the following link :
> > > > https://forms.gle/a1x26WQGzURLerv66.
> > > >
> > > > 4. Application Form: Documentation / Technnial Writer
> > > > Collaboration
> > > > There is a section to fill in about experience with
> > > > docum

Fwd: ASF Application for Google Season of Docs 2019

[Joan Touzet]

Any interest? Note: we'd need *2* mentors from CouchDB to help drive this.

-Joan

- Forwarded Message -
From: "Sharan Foga" 
To: d...@community.apache.org
Sent: Tuesday, 2 April, 2019 5:03:06 PM
Subject: ASF Application for Google Season of Docs 2019

Hi All

As mentioned the applications for the Google Season of Docs opened today and 
I'm working my way through it on behalf of the ASF. 

If accepted, we will be allocated either one or two techical writers. Google 
will also pay the ASF a stipend of $500 per technical writer mentored (which I 
hope can go directly to fundraising :-)

Each project that wants to participate must provide two mentors for each 
documentation project.  

As part of the application process there are a few things that we need to setup.

1. Season of Docs Page and List of Project Ideas
We need to create a public webpage about Season of Docs that contains the list 
of project ideas for documentation. I have created a page on the ComDev wiki 
https://s.apache.org/w4CH  with a table for projects to record their ideas.

2. Alternative administrator.
I’ve set myself up as the primary admin and Maxim as the alternative admin 
(Maxim, I need to confirm your contact email and you will also need to register 
as the alternative admin and I will email you the link offline)

3. Mentors
All mentors from the projects interested in participating must register 
individually at the following link : https://forms.gle/a1x26WQGzURLerv66.

4. Application Form: Documentation / Technnial Writer Collaboration
There is a section to fill in about experience with documentation and any 
previous collaboration with technical writers. I know a few projects have used 
various tools for documentation - but not sure about any technical writing 
collaboration (so if you know of any then please let me know)

5. Application Form: GSoC
There is a section to complete at our participation in GSoC.I think I have the 
details from our application this year so can follow up with Maxim or Uli about 
it

This is all I have at the moment and we have until the 23rd April 2019 to 
finalise all the application details. Ideally I want to have it done well 
before then :-)

Please pass on this information within your various projects and as with GSoC - 
I'll see how we can get this information out to all our project mailing lists.

Thanks
Sharan



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

Re: on "meritocracy"

[Joan Touzet]

Griselda Cuevas  wrote:
> @joan - I also get a Pony, I requested the Jira ;)

Of course you do!

(Use a monospace font for best rendering...)

,--,
  _ ___/ /\|
 ;( )__, )
; //   '--;
  \ |
   ^^

-Joan "Caaan do!" Touzet

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

Re: Welcome to diversity@apache.org!

[Joan Touzet]

Ahoy hoy! Glad to be here.

On 2019/04/02 17:10:45, Daniel Gruno  wrote: 
> Hi hi folks!

-Joan "time for another mail filter rule" Touzet

-
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Re: on "meritocracy"

[Joan Touzet]

Daniel wrote:

> Requested, and should be ready within an hour or two.

Thank you! You get a pony!

-Joan "JFDI" Touzet

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

Re: on "meritocracy"

[Joan Touzet]

Daniel Gruno  said:
> On 02/04/2019 11.34, Joan Touzet wrote:
> > Daniel said:
> >> On 02/04/2019 11.29, Daniel Gruno wrote:
> >>> On 02/04/2019 11.26, Joan Touzet wrote:
> >>>> Trying to cut through the bikeshedding:
> >>>>
> >>>> Daniel Gruno  said:
> >>>>> I'd recommend a separate mailing list (to provide focus) and a
> >>>>> JIRA,
> >>>>> perhaps some place to put documents (either within the comdev
> >>>>> svn
> >>>>> area,
> >>>>> or somewhere else if spun off), and then...just get to work :)
> >>>>
> >>>> This is what Griselda proposed as well (yes, and other things).
> >>>>
> >>>> Can we get these now (under ComDev) and move them later when the
> >>>> president's committee is approved? (And, if not, they can stay
> >>>> under
> >>>> ComDev)?
> >>>
> >>> Yes, we can request them right now (within 3 hours), we just need
> >>> to
> >>> pick a name for the list (gimme some suggestions!) - and probably
> >>> just
> >>> pick the same name for a sub dir of comdev's svn. the JIRA
> >>> instance
> >>> is
> >>> already requested via a ticket.
> >>
> >> perhaps we should just make divers...@apache.org and get started
> >> there?
> >> the advantage being that it's not tied to a project, so whatever
> >> we
> >> end
> >> up with, it wouldn't affect the list.
> > 
> > Well, we have the JIRA already:
> > 
> > https://issues.apache.org/jira/projects/DI/summary
> > 
> > divers...@apache.org works for me; if the president's committee
> > doesn't
> > get approved, would we have any pressure to move that to
> > diversity@community.a.o instead?
> 
> No, not really :) there's plenty of precedence for keeping it.
> Assuming this would be a public list (feedback??), I can get it
> created
> ASAP.

Public, but non-member posts get moderated. (I forget if this is the
default.)

-Joan

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

Re: on "meritocracy"

[Joan Touzet]

Daniel said:  
> On 02/04/2019 11.29, Daniel Gruno wrote:
> > On 02/04/2019 11.26, Joan Touzet wrote:
> >> Trying to cut through the bikeshedding:
> >>
> >> Daniel Gruno  said:
> >>> I'd recommend a separate mailing list (to provide focus) and a
> >>> JIRA,
> >>> perhaps some place to put documents (either within the comdev svn
> >>> area,
> >>> or somewhere else if spun off), and then...just get to work :)
> >>
> >> This is what Griselda proposed as well (yes, and other things).
> >>
> >> Can we get these now (under ComDev) and move them later when the
> >> president's committee is approved? (And, if not, they can stay
> >> under
> >> ComDev)?
> > 
> > Yes, we can request them right now (within 3 hours), we just need
> > to
> > pick a name for the list (gimme some suggestions!) - and probably
> > just
> > pick the same name for a sub dir of comdev's svn. the JIRA instance
> > is
> > already requested via a ticket.
> 
> perhaps we should just make divers...@apache.org and get started
> there?
> the advantage being that it's not tied to a project, so whatever we
> end
> up with, it wouldn't affect the list.

Well, we have the JIRA already:

https://issues.apache.org/jira/projects/DI/summary

divers...@apache.org works for me; if the president's committee doesn't
get approved, would we have any pressure to move that to
diversity@community.a.o instead?

-Joan

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

Re: on "meritocracy"

[Joan Touzet]

Trying to cut through the bikeshedding:

Daniel Gruno  said:
> I'd recommend a separate mailing list (to provide focus) and a JIRA,
> perhaps some place to put documents (either within the comdev svn
> area,
> or somewhere else if spun off), and then...just get to work :)

This is what Griselda proposed as well (yes, and other things).

Can we get these now (under ComDev) and move them later when the
president's committee is approved? (And, if not, they can stay under
ComDev)?

I want to get started with reasonable, motivated discussion and not
lose momentum while we wait a few weeks.

-Joan

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

Re: Building and Sustaining Inclusive Communities (was: on "meritocracy")

[Joan Touzet]

Thanks for this post, Shane. You share a number of my concerns.

I am absolutely not blind to opposition to some of the things I've
suggested, but I would argue that the thread on the topic has become
so negative and heated that informed discussion isn't useful.

Again I encourage others to listen to and read my presentation to
hear my concrete, achievable suggestions, and others' reactions to
them at the meeting.


- Original Message -
Shane wrote:

> A situation that's happened to me personally with saddening
> regularity:
> I come up with a new idea to improve a process or document, and ask
> for
> feedback.  Some of the feedback asks "why are we bothering with this"
> or
> "I think that's wrong because X", or merely asks clarifying questions
> /
> requests for more additional data, or or or... and often ends up
> being
> an endless game of "fetch me a rock".
>
> After attempting to answer a half-dozen of these questions - many
> tangential or merely expressing opposition *without providing useful
> alternatives*, I simply run out of volunteer energy and give up on
> the
> idea completely, and I find some other place to spend my time.  The
> opposition of just a couple of people spending the time to keep
> asking
> for clarifications can often turn into a de facto veto for all sorts
> of
> new ideas.

Yes, this is exactly the war of attrition that I'm trying to avoid in
my last post. It shouldn't be up to me to endlessly rebut all of the
attacks on this; they've been written hundreds and hundreds of times
to date, even limiting yourself to open source development. It's not
my job to rehash this yet again for another newcomer to the discussion.

The concern trolling assumes bad intentions on my part. I think the
proposals I've made speak for themselves as not being ill-intentioned,
and don't step too far. They are in the Apache tradition of small,
incremental, reversible steps.


> 
> Apache communities work better when people who think a new idea is
> [dumb
> | annoying | not useful | whatever ] simply raise the general concern
> once, but otherwise get out of the way.  We're all volunteers; we all
> have opinions; we all have things we want to work on in our different
> communities.  We can respectfully say we don't like some new idea,
> but
> it's not up to any of us to stop other volunteers from doing that new
> idea that they're passionate about.
> 
> Even better: when you don't like a new idea, come up with a better
> idea,
> and volunteer your own time in a new thread to productively work on
> it.

Yes, I'd like to shift the discussion in this direction.


> Bonus link, that I hadn't seen before but I really like the
> *explanations* behind this organization's social rules:
> 
>   https://www.recurse.com/social-rules

Pretty sure I linked to this and mentioned it in my presentation,
too. :)

-Joan "let's talk action" Touzet

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

Re: on "meritocracy"

[Joan Touzet]

"Wade Chandler"  wrote:
> 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.

Naming and shaming in a public forum isn't a good idea.

Situations where there have been individuals who were actively working
against inclusion have, in my experience, been dealt with on a need-to-
know basis. And yes, it has happened here at Apache.

> On another it “can” actively try to
> attract more diversity; intentional positive; not sure I see this at
> Apache.

Precisely the point. I'm in favour of this, though I know others are
actively against it. I talked about this at length during my
ApacheCon 2018 talk, proposing options that are well thought-out and
fair, drawing from a wide variety of sources; I encourage you to
listen to the full recording and read my slides before passing
judgement.

This effort can be engaged on a project-by-project basis, by the way.
It doesn't need consent from people on this list.

> 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.

And it's obvious to me, at least, that just doing this has been
insufficient. We need to cast our net wider. Rich said earlier in this
thread:

> 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.

So yes, there is clearly a stated desire to improve, from the board
level down.

> 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.

To me, this reads as you saying "We're promoting women and minorities
just because they look good for our D&I numbers, not because they have
the skillsets required." Was that what you really intended to say?
If so that's borderline offensive, but as you say, irrelevant to
our situation at Apache - so why bring it up? I'm trying to assume
good faith on your part, but finding it hard to do so.

> 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.

On the contrary - we say "Community Over Code" is a core guiding 
principle of the ASF. So if that's the real thing that matters to us,
and we state it loud and clear on our website, why aren't we deciding
who gets "merit" based on that clearly and loudly, just as much as
we care about code contributions?

> Marginalized has a very specific and strong meaning; one of intent.
> Do you intend to use it per that meaning?

Not to speak for Naomi, but:

It does not have that. Relegation to the margins may be transitive
in nature, but it can be inadvertent. Learning to stop talking and
let others who may not talk as often is an important skill in meetings,
as is asking those who rarely speak to speak up another in encouraging
good team development. To find yourself edged out, unheard or ignored
is a common enough situation for people "at the margins." It doesn't
necessarily refer to active maliciousness on the part of the
marginaliser (though it can).

I'm not going to go into detail, but reading up on the topic of
inherent biases in cultural norms might provide some background here.

> 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.

Again, not all contributions are code, and not everyone who gains merit
does so through writing it. Some really great people here at Apache
don't write code, have tons of merit, and just happen to be women and
minorities. Your choice of words above indicates you wouldn't consider
these people to be worthy of consideration - was *that* intentional?

> Similar to a company, requiring care and feeding, which regardless of
> anything else, would not hire someone with the wrong skillset nor
> re

Re: on "meritocracy"

[Joan Touzet]

> TL;DR: identify a list of tangible deliverables, and I'll help you
> make it happen.

In the interest of not losing sight of the meritocracy debate, along
with the D&I work (which I'm happy to engage on, someone sign me up),
we need to actually solve the original "meritocracy" problem. I
proposed some concrete approaches, and I think Bertrand here has the
lead since he's working on the website refresh. (Please correct me
if I'm wrong.)

Suggest we move that messaging point over to Bertrand's group, and
have the new sub-ComDev D&I group focus on the latter half of this
thread.

Does that make sense?

-Joan "cuttin' back to basics" Touzet

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