Download to read offline
Pain points of learning and contributing in the Drupal Community
- 1. Pain Points ofLearning and Contributing in the Drupal Community May 13, 2015 Kalpana Goel Frédéric G. Marand Collaborative notes taking: http://bit.ly/contribution-notes
- 2. Nice to MeetYou Kalpana Goel Developer at Forum One Drupal.org/IRC - kgoel Twitter - @kalpanagoel Frédéric G. Marand Developer at OSInet Drupal.org - fgm Twitter - @osinet Pain Points of Learning and Contributing in Drupal Community
- 3. Pain Points toCore Contributing Pain Points of Learning and ● Finding right issue to work on ● Fear of not knowing much ● Trouble finding right mentor
- 4. Pain Points toCore Contributing Pain Points of Learning and ● Lack of code reviews ● Can’t RTBC your own patch ● Takes too much time to add beta evaluation
- 5. Barriers to CoreContributing Pain Points of Learning and ● Pressure to finish the major/critical issue ● Scared to comment if not sure ● Time and money
- 6. Subsystem Complexity Pain Pointsof Learning and
- 7. ● API pagesare mystifying ● Doc pages are Misleading ● Module handler ● Creating an entity Quality of Documentation Pain Points of Learning and Contributing in Drupal Community
- 8. What is continuous contribution? PainPoints of Learning and ● Working on Drupal a little often
- 9. Benefits of continuous contribution? PainPoints of Learning and ● Up to speed with core ● know Drupal core more broadly ● Are aware of trends in core
- 10. What is sporadicContribution? Pain Points of Learning and ● Working on Drupal in depth, but not so often ● e.g. only in code sprints
- 11. Benefits of sporadic Contribution PainPoints of Learning and ● Unblock hard problems ● Avoid burnout Downsides ● Never close an issue ● Never be aware of events
- 12. Pain Points ofLearning and Contributing Over Time ● Started Drupal in 2010 ● Started contributing before DrupalCon Portland 2013 ● Worked on issue during DevDays: 98 comments before RTBC, 114 to commit ● Average time to get reviews for issues - 7 days
- 13. Pain Points ofLearning and Contributing Over Time ● Started Drupal in 2005 ● Started contributing a month later ● Open core issue first comment: RTBC, second comment: Committed ● Average time to get reviews for issues - 32 days
- 14. Pain Points ofLearning and Contributing Over Time Long issue release cycle means less motivation
- 15. How does thisaffect contribution ?
- 16. Pain Points ofLearning and How to break the trend so that more than 20% new contributors have more than 5 commits?
- 17. Pain Points ofLearning and Credit: http://xjmdrupal.org/blog/contribution-influence-drupal-8 How do we soften the curve?
- 18. How can weencourage more contributors to work on major/critical issues? Pain points of learning and contributing in the Drupal Community
- 19. http://bit.ly/node999 Feedback Pain points oflearning and contributing in the Drupal Community Notes http://bit.ly/contribution-notes
- 20.
Editor's Notes
- #2 [kalpana] Welcome everyone, today we are presenting our ses sion on Pain points of learning and contributing in Drupal community.
- #3 [kalpana] I work at Forum One. We are full service digital company and we do lot of Drupal work. fgm, OSInet is a consulting company specialized in Drupal performance, mostly for media sites in the EU
- #4 [kalpana] How many of you have experienced pain contributing to core? Finding right issue to work on - this is the biggest challenge to find right issue to work on. something you pick that you are very passionate to work on but find it challenging to work on. Fear of not knowing much - So if you pick some issue to work on , you might think that you don’t know enough to work on the issue Trouble finding right mentor - You are brave to work on an issue but you want little guidance. But how would you find right coach who can guide you through that issues
- #5 [kalpana] Here are some other pain points Lack of code reviews - It’s hard to get code reviews. Yesterday’s YesCT and alimac session about Drupal.org changes to support first time contributors and mentors discussed about automating coding standard part of the patch reviews on issues so the reviewers are more likely to give the good code reviews. Can’t RTBC your own patch - Suppose two person worked on the issue and Person “A” worked on the issue most and Person “B” did some minor changes to person “A” patch. Person B can’t RTBC patch. Adding beta evaluation - For a new person, it takes 1.5 hour to add beta evaluation and an average time, it takes 20 - 25 minute. Explain what is beta evaluation
- #6 [kalpana] Pressure to finish the major/critical issue - Since we are getting close to release, there’s a pressure to work on the issue and post a patch. Scared of picking issue (scared of picking some issue to work on if one of the top contributor is working on the patch) Scared to raise concern in the issue if not sure? (Do you feel like that you don’t understand the subsystem completely to raise valid concerns?) Time and money (Does your company or yourself recognize and value the importance of contribution as an asset ? Myself as a woman, I don’t have much time to work on core outside my daytime job and I have household duties to fulfill. Finding time for 3rd job is hard. Its unpaid job.
- #7 [fgm] Entity, Field, Plugins, Configuration Management say why the above subsystems are complex Drupalisms
- #8 [fgm] you can use api docs for reference but to get the introduction, you go to drupal.org for a guide, but it has stale docs so there is a connection but it’s broken? Module handler? What is it? What does it do? Creating an entity https://www.drupal.org/node/2166447 How does it relate to reality ?
- #9 [kalpana] Working on Drupal a little bit every day or at least every week : This is continuous contribution basically don’t have a life (No, I am kidding).
- #10 [kalpana] some of the benefits of continuous contributions are up to speed with core - so you work on core and become continuous contributor, you work on different subsystems and issues.. you become familiar with core know Drupal core more broadly - Gain knowledge of different subsystems aware of of what’s going on in core, where most of the activity is taking place, you get to be part of the decision making in core. you can provide insights, share your ideas
- #11 [fgm] Working heavily, but only during code sprints : this is sporadic contribution So you come to attend some Drupal event and contribute only during sprints, after attending event, you go back to your day job
- #12 [fgm] what are some benefits of sporadic contribution - you work on hard problems (by either posting code reviews, architectural decisions, or even post a patch! Avoid burnout - since contributor is contributing during sprints so they avoid burnout Both are needed, but most issues are solved by continuous contribution, because they take such a long time to solve that sprints are not sufficient to move the issues forward
- #13 [kalpana] Average time to get reviews for issues - 7 days which is awesome because its faster than average time
- #14 [fgm]
- #15 [fgm]
- #16 [kalpana]
- #17 [kalpana] So here we can see some trend in number of contributors - losing momentum in 2012 - we had 18 new contributors per month with more than 5 commit mentions 2013 - we had 18 2014 - 16 contributors 2015 - 14 contributors we have Total: 2862 contributors
- #18 [fgm] if you look at this chart, the green line is sharp and shows long tail of contributors. we want to raise number of repeated contributors, and contributors with 5 or more commits to have continuous contribution so we can soften the curve