Following the EPrints Hack Day which was connected with the last EPrints Uk User Group Meeting, I have been thinking about the nature of community engagement. There is a history of hack days at which members of the technical community have contributed to EPrints, but there has been far less engagement from the larger non-technical side of the community. I wanted to try to change this with an event targeted at all members of the community.
The Community Contributions Day was intended to provide a big tent under which all members of the community could pull together on a number of areas of interest. We organised via a page on the EPrints Wiki, where we asked the community to suggest Interest Groups that people could join. After some evolution, these became:
- Group 1: Community Training Course
- Group 2: Technical
- Group 3: Community Contributions, Best Practices and Processes
A smattering of community members signed up for each group, and we got going. Here are each group’s report in their own words:
Group 1 Report
- Mick Eadie
- Adam Field
- Lizz Jennings
- George Mamalakis
- Patrick McSweeney
- Rachel Proudfoot
- Alan Stiles
Interest Group 1 was looking at the video training course on the wiki. The training course has been a community effort over the past year to produce training videos for EPrints which can be tied together on the wiki into comprehensive training courses for EPrints users, administrators, developers. Here is what we achieved:
- Training Course Page Template: We wanted a standard for training course pages which would give a consistent user experience for learners. Once we had decided on the structure, we created a template page which could be copied and pasted on the wiki.
- All training videos now have indices on youtube.
- Having created a standard page layout, we rolled the template out across all training video pages.
- We discussed the content of the course, and identified a number of missing training course pages, putting in headings for videos that will be produced in the future.
- We added a section to the training course page to help contributors engage with curating the course.
- We created a new training video, and its associated wiki page.
- Some tidying, linking and more sensible use of the category were also achieved.
The day has taken a collection of videos with little context and produced what’s starting to look like a proper training resource for EPrints. We hope we have also made it easier for future development of this page to be done by members of the community.
Group 2 Report
- Valerie McCutcheon, University of Glasgow
- Rachel Proudfoot, University of Leeds
- Les Carr, University of Southampton
- Adam Field, University of Southampton
What problem were we looking at?
- Accessibility of information about EPrints
- Getting more engagement from the community
- Wiki curation
How did we work?
- Collaborative Google doc
- Direct edits onto the eprints wiki
- Organise early with clear, lay-friendly explanation of event.
- Have one agreed communication channel between any organisers on the day of the event.
- Reduce barriers to participation by having some clear tasks agreed beforehand; ideally, strike a balance between some structure and enabling innovation and creativity on the day.
- Everyone can contribute something.
Group 3 Report
The technical team consisted of John Salter, John Beaman, Patrick McSweeney and fleeting visit from Rory McNicholl. The technical aspects of EPrints offered us a variety of opportunities to explore. We started by talking about scratching an itch John had with licences from there the conversation passed by the difficulties of making a Bazaar package and end talking about build environments generally. We talked about the efforts to get Vagrant build set up, something John xxx was keen to continue working on. John S and Patrick then moved on to talking about the issue of outstanding bugs and pull requests. We sat down to look at the bugs list to get a feel for what was out there.
It quickly became apparent that there were plenty of bugs which could be quick fixes. We labelled these accordingly and then started thinking about what to fix. The decision was made to leave simple bugs for people with less experience and look at some of the bigger issues arising. There are some problems in creating an environment where new pull requests can be tested to make sure they are not breaking existing functionality. We concluded the appropriate thing to do was create some instructions about building a environment suitable for testing contributions and doing development work. John ran up against difficulties in building an environment in Centos but Patrick had some success on Ubuntu. He then spent some time getting to grips with running the automated tests and understanding the output. With the documentation created we are making it easier for people to develop and test changes they are making to the EPrints core. Hopefully this means we can take advantage of community pull requests which exist but we can not merge with confidence. Currently there are a number automated tests which do not pass on EPrints 3.3 branch and we intend to resolve this as a Christmas present to EPrints
Outputs of the day
- Labelled about 50% of the github issues.
- Made further progress on a Vagrant build
- Made significant headway in adding command line flags to epadmin create to repositories can be built without human interaction
- Added a new label called “quick fix” which should help identify problems which easily solved
- Documentation about how to build a Ubuntu dev environment on the EPrints Wiki
- Gained understanding of how to run the automated tests and did so with the following results
Files=41, Tests=2333, 42 wallclock secs ( 0.49 usr 0.09 sys + 37.09 cusr 2.84 csys = 40.51 CPU) Result: FAIL Failed 3/41 test programs. 58/2333 subtests failed.
- 2 new pull requests (proposed bugfixes)
- 3 issues closed
- 35 issues tagged and categorised
- February 2016
- May 2016
- August 2016
- November 2016
–Report by Patrick McSweeney
I hope this day has given community members experience in editing the wiki, and will start to promote a sense of ownership over this resource. Here are the number of wiki edits on the 18th, and the 19th (some community members just didn’t know when to quit).
Firstly, 308 contributions!!! Amazing. There’s no way we can argue that that wasn’t a productive day’s work.
While developers outnumber non-developers in this list, the great news is that we got some involvement from the non-developer EPrints community who made significant meaningful contributions. Hopefully this will lead to greater involvement in future events.
One outcome not to be ignored is the visibility this kind of event gives of the kind of jobs that need to be done on the wiki. That, coupled with the experience gained by newer members of the community could lead to a better curated wiki.
Stats from github are slightly harder to get and atribute, but:
This is a meaningful contribution to the management of the EPrints codebase. However, much of what the technical team got done will (as is often the case with the technical team) bear fruit further down the line.
Communication about the event was an issue. While the technical community is used to the idea of contributing to EPrints, it was difficult to engage with the repository administrator / editor sectors of the community. Finding a way to better engage with this part of the community is key in making the next event more successful.
Platforms to use on the day were also an issue. Group 3 used Skype as they were small, group 1 unsuccessfully tried to engage with each other over a Google hangout before moving to a google doc, and group 2 (also small) made successful use of a Google hangout. Having a community member with experience in remote events facilitating communication would have made the start of the event a lot smoother. Any volunteers?
We got a lot of really useful work done! We should do this again. We should do this every 3 months! Tell all your friends and rope all in that you can. EPrints is only ever as strong as its community, and the community is really only as strong as the core members that actually contribute. Making that core larger is key in community sustainability.
Proposed 2016 Community Contribution Days: