I became involved with the PeerLibrary project through a classmate in our Open Collaboration and Peer Production Class. I informally introduced myself in person and offered to lend a hand wherever help is needed—this part was very easy in my case! As a first-time open collaboration contributor, it has been really nice to be able to meet other project contributors and leaders in person and to discuss the needs of the group and vision going forward, as well as to observe the emerging communication structure both online and in person.
Being new to this type of project, I appreciate having a small community to point me to the most useful resources that apply to my planned contributions. Also, though the project itself is no small feat, it feels much more manageable to eventually gain an overall grasp of both the overall structure and many details for this type of early-stage project than if I were to try to contribute to a large, long-running and already widely used project.
Since much of the work to be done at the current phase of the project is programming, and because I am very interested in learning a web app framework (PeerLibrary uses Meteor my goal is to contribute to the source code of the project. So far, I have successfully run a local instance of PeerLibrary and have been able to play with the tool in its current state of development. I have been learning and absorbing through listserv message archives and issue tracker items, which document bugs to be fixed as well as features in the works (or at least under consideration) for the near and distant future. Using this limited knowledge I have been able to make a few constructive contributions: clarifying documentation and one bug report. I have also reached out to the new group developer’s listserv to introduce myself to those I haven’t met yet. I think there are a few people on the listserv who have just been “lurking” so far, and I’ll be interested to see how the group incorporates new interested members from outside of the UC Berkeley community as PeerLibrary grows and more people become aware of it.
Since PeerLibrary is a fairly new and small community, the newcomer pipeline has not yet been solidified. Stemming from the struggles I encountered while trying to get a local instance of the web app running on my machine, I hope that the documentation changes I have contributed will help decrease someone else’s barrier to participation in this project. The experience of updating documentation has also made me think about the importance of gaining perspective from new collaborators when describing a process that is required to join the project, especially as the project evolves. How do we know when a prospective collaborator is not expressing interest in getting involved because they are confused about some aspect of the process and embarrassed to ask a question, or because they are genuinely not intending to contribute? It seems that this problem would get more pronounced as a project grows in scope and becomes a community that communicates primarily online. My experience has so far been quite personal, but I hope that I can keep these issues in mind as we continue to get the word out about PeerLibrary. It seems the challenge lies in creating a process that allows for general inquiry and feedback, but feels personal without overwhelming the project contributors. PeerLibrary, for example, has a separate issue tracker tag called ‘repository’ that anyone can use to alert the team of open source archives that exist, but haven’t yet been incorporated into the tool. Perhaps there are other opportunities to invite such useful, structured feedback that we can take advantage of.