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-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
