How the PeerLibrary team works

Technical Modularity

I think the community of PeerLibrary mirrors the technical modularity of the project and all this happened very organically. I think it started initially with everyone wearing all the hats and now as the community is growing, contributors are taking up certain modules and owning them. I work mostly on the design, blog and community outreach, Angelica works on all the written material and outreach, Tony works on client side code and front-end stuff for PeerLibrary, Anna is working on creating an admin dashboard now, Mitar works on infrastructure and server side code, and finally Rodrigo works on everything in between: code that require both client server communication, new features, fixes etc. This structure has never been formally decided, and as far as I know everyone just picked what they really liked to work on, and it ended up mirroring the technical modularity. I think this is great and it helps keep people out of each other's way and also helps because it people organically take ownership of issues.

Collaboration Patterns and Getting Work Done

Contributors collaborate synchronously as well as asynchronously. As discussed in some of my earlier assignments, the team works together synchronously during regular meeting times and through communication on IRC. Github issue tracking and pull request comments also allow contributors to work asynchronously.

Most of the work gets done through tracking open issues on Github or through the goals set for each milestone (which are set in advance for each stage). When a member wants to work on an issue, they create a separate branch and submit pull requests when the work is ready for review. People then discuss the change by commenting on the pull request and once consensus is reached the code is merged. Full details on the development model and process used can be found here. So having the community mirror the technical modularity really helps in this process as people already own certain aspects of the project and end up taking responsibility for the issues related to their area of specialization. Managing tickets become easy, and it helps the contributors stay focussed.