We had a lot of new participation for the last couple of weeks on developing the site webcompat.com. That's encouraging.
First of all thanks for the new contributions of:
- Dulshani Gunawardhana, Sri Lanka
- Decky Coss, New-York (USA)
- Carol Chung, Los Angeles (USA)
- Deepthi Venkitaramanan, Bangalore (India)
This is due to the Mozilla outreachy program.
An sudden surge of participation means also new good challenges for our community. From the top of my head this week:
Reading Again your Code
New contributors questions on simple things are forcing you to review your own legacy code. Explaining is the best way to understand again some of your choices or to find dead code.
Contributing Guide
We (webcompat.com) needs a better 101 guide on how to contribute to the code. For a while with Mike, Guillaume, Daniel, Hallvord and Alexa, we kind of agreed on ways to manage the project. More specifically, we have half-written rules for:
- Coding style
- Commit style
- Pull Requests Process
- Review Process
We need to make these a bit more explicit. When a new contributor is not necessary skilled with git and Github and/or has different habits for working with code, we spend time on fixing the code, he or she just wrote. It probably creates frustration for the new contributor to have to redo things. Providing clear guidelines can help a lot a new contributor to avoid the pitfalls of style and make it easier to focus on code (aka the fun part). It also might remove anxiety in the participation.
Changing your own Job
These last two weeks, I spent a lot less time on doing the job and more on helping others do the job. It reminded me when I was the technical director of a Web Agency for a team of 20 developers. Not much time for coding, but trying to help everyone with their questions and where to find the answers (instead of giving the answer). I'm personally always challenged by these two roles. I like coding, but I also like helping others.
Healthier Community
Having more participation on a Mozilla project is healthier, specifically when there are more volunteer contributors. It means the community owns the project in some fashion. It exists because the community needs it, more than Mozilla needs it. It's even more important for a project like webcompat.com which wants to be cross-browser, even if we haven't seen a lot of participation on the browser side except for Microsoft at the beginning.
- The webcompat.com coding part is healthy and even more so since the last few days. Let's hope that some of the new contributors will stick to it.
- The Web Compatibility issues analysis and outreach still are still too dependant on our Mozilla employees team effort.
Coding a Project / Using a Project
This is personal.
I'm always careful when new contributors arrive through a program driven by a chance of getting something out of it, specifically in such a project as webcompat. Coding for the project is fine and it's valuable. Getting experience on it is really cool for both the community and for the individual participating. But there is also the big picture of the project. Are you interested by the goals of the project itself? Is it something which you think the mission is important? Or maybe it's just my own personal bias, where I think you should try to work for places where you have a certain degree of affinity with the project, the company, the mission. There are certain companies of the Silicon Valley I would not work for, not because of their employees, or the awesome or challenging projects they are developing internally, but because of the global mission of their activity. Facebook and Google are two of these because of their ads goal. The same way as a physicist, I would not work the nuclear industry. Huge means, interesting challenges, projects with big impact, but that pinch the wrong chord of my own ethics.
Otsukare!