community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sharan Foga"<sha...@apache.org>
Subject Committer Diversity Survey - Improvements Related Feedback
Date Wed, 15 Mar 2017 10:12:48 GMT
Hi Everyone 

I'm following up on some of the feedback received in the Committer Diversity Survey. 

https://cwiki.apache.org/confluence/display/COMDEV/ASF+Committer+Diversity+Survey+-+2016

The last survey question was one where they could leave any comments or feedback and also
give their explicit permission for us to quote or use their comment.

The following comments were received about suggestions for improvements. Please note that
one of the comments referred to a specific ASF project which I've changed the name  to Project
X.

1. ASF should gather committers to know each other and communicate with each other.

2. I really wish that it would be made very clear and easy to donate to the ASF.  Put a button
right next to the feather on the front page.  I'm sure many people actually give up trying
to give the ASF money!

3 .Apache foundation should setup conference in asian countries to get more influence there
and enhance open source movement.

4. Guidelines, where they exist, are not necessarily hard to find; sometimes.  To me the issue
is that the guidelines aren't co-hesive (in presentation/organization) or not well explained.

5.More students could be targeted for involvement at the ASF.

6. ASF often uses the term "meritocracy" to refer to its governance structure, apparently
forgetting the satirical origins of the term, and erasing the fact that "merit" is a somewhat
slippery concept in open source (whether someone contributes to a project is probably much
more a function of how much spare time they have, alongside their job, family commitments,
etc., than of their actual ability). I would prefer the ASF to be more thoughtful in the words
it uses.    Glad you're doing this survey though -- diversity is an important topic and it's
good that it is getting some attention within the ASF.

7. I think an Apache committer handbook would be a good project to start, condense all the
knowledge to a book/website probably using something like ReST or markdown. ReST has benefit
of using sphinx to create a webby and pdf.

8. Sometimes processes can be a pain.....

9. In general the ASF does a poor job of differentiating between "rulings" and "opinions of
one or more active Members". That's why I answered that it's difficult to find info about
processes, policies, and guidelines: the info is easy to find but it's hard to understand
what is a hard and fast rule vs a "some ASF member with commit privileges to this web page
decided to write some opinions down".    I've seen this cause a lot of consternation for people
new to Apache, especially in the context of the incubator. Podlings I've mentored have come
away really frustrated trying to parse what exactly is required of them before they can call
a graduation vote, and understand if criticism from various IPMC members is an expression
of opinions vs actual "rulings".    This may not immediately seem like it's related to diversity,
but I do think it hurts inclusion: people come away with the sense that it's not about following
some prescribed set of processes and rules, but more about who you kn
 ow and how good you are at politicking/arguing on mailing lists that determines whether a
project can survive incubation.

10. Being employed to a company with a continuing commitment of opensource - at least implicitly
- this may be in retrospective the reason I am (still) working there. Supporting Apache projects
does also mean supporting myself, which means my day to day work becomes easier being a bit
like "on a giant´s shoulder" in quite many aspects. While hopefully achieving positive
results this way for me, the company, the project, the opensource community and the Apache
Software Foundation as a whole, which is of course outside my scope, this is one of the best
matches I could think of. 

11. Information about legal frameworks and processes is best found by searching mailing lists
for similar cases, or asking more experiences people directly (Shane is very helpful!).  
 The docs are often not so easy to locate, and not super well organized.

12. The ASF is too US centric.

13. Some mentors are not active at mentoring podling projects except for their employer. We
know they are very busy but we can better to improve mentor's commitments or the incubation
process itself (reducing mentor's tasks).

14. I had two original goals joining Apache Project X:    1. Contribute changes needed for
my day job so that I spent less time maintaining a fork and could make those improvements
available globally. This quickly became a gateway to learning the source code structure so
that I could help other developers contribute to Project X . Since joining roughly 14 months
ago, I have suggested two active community members join the Apache Project X PMC, who were
initially after the same thing: reduce the time spent waiting for work-related patches to
committed. Both have started branching out into working on Project X outside of their day
jobs. 2. Learn how software development, releases, and communication works in Open Source
projects. This was my first open source project at the age of 25. I also wanted to learn about
secure (PGP) communication and get established in a web of trust. I am still working towards
this.    A few things have happened since joining Project X. I have travelled around
  the world (California to Germany) to spend several days with two Project X developers. Joining
Apache opens up a world of trusted developers who share a common interest (software) but have
very different hobbies to color life-lasting experiences. I encourage every Apache developer
to travel and do something--mountain biking, rock climbing, surfing, kayaking, swimming, camping,
or wine tasting with several developers on their project to extend the virtual, timezone-split
relationship we have into the physical world.

15. I think the ASF guidelines are difficult to navigate and also somewhat incomplete. I stumbled
upon vague guidelines in the past that I did not know how to handle or interpret.

16. The English only community is a burden to me. Maybe it is not, but I have such a feeling.

17. Individual contributors who express interest in the contributing to a project must be
welcome with open arms. All Apache projects must be well documented so that a new developer
can quickly jump in and start contributing.

18. Sometimes folks makes a comment in a jira, especially disagreement ("-1"), and never address
back even if pinged many times. This indicates that either they no longer work on the project,
or they changed mind about their original disagreement but don't bother commenting back, or
they don't care about it anymore. However, their original comments still serves as a blocker
for further progress.     We need a policy to unblock this situation, for example, expiration
of "-1" (such as pinged 3 times, and no comment back in 3 months) if they don't comment back
as long as there are other committers +1.    

We also had eight comments where people did not give their permission to be quoted so I have
paraphrased the general feedback below:

-The first mentioned that project board reports don't contain enough information to get a
real insight into what is happening in a project so the suggestion was to setup a common area
where committers can find out details about what is happening in other projects.

-One person thought that our big data projects are too influenced by commercial companies
and are not working the Apache Way and so making it very difficult to gain enough merit to
become a committer. 

-Another was related to duplicated incomplete versions of guidelines, processes and policies
that are not consistent. (e.g one says one thing and another says something different)

-One highlighted that finding information had really improved recently.

-One suggested having a regular Apache Conference in Europe and America.

-One feedback was related to updating ASF development process and suggesting the use of Git
over SVN and social chat rooms rather than mailing lists.

-Two were about meritocracy, one suggested that it was not attainable and if Apache abandons
it then we could really start working on the real issues while the other saw meritocracy as
the source of all things Apache.

As you can see engaging our commmitters with this survey has produced a lot of interesting
ideas and suggestions!

Thanks
Sharan 

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


Mime
View raw message