Developing in the Open

This is my first, long overdue blog post since starting my new role as Software Configuration Manager for OPF at the start of the year.  Truth be told that between the SCAPE end of year and review, a weeks holiday, and working out what to do it doesn't feel like four months since I started.  I'm the OPF's first full time technical team member and will be dividing my time between:

  • improving the quality of software developed under the OPF's GitHub Organisation's banner, and other open source tools used by members.
  • offering guidance and assistance to developers working OPF software with best practices, and use of online tools.

  • helping to improve user documentation of software so that it’s easier to find and use.

  • showing members how to help shape future development of tools they use, by helping to convert requirements into developer tasks and automated tests.

  • engaging with the developers of open source digital preservation projects in order to share ideas, and software.

  • providing technical expertise and meeting members at OPF Hackathons and other events.

  • contributing to external projects the OPF is involved in, e.g. SCAPE & SPRUCE.

The OPF GitHub page currently lists 50 public projects. To put that in perspective I could afford a week of effort a year per project, if I did nothing else and took no holidays. In reality it would be no more than 2 days a year per project.  The projects are in varying states of activity, are written in different programming languages e.g. Java, Ruby, Python, PHP, and some aren't software projects at all.  Between other tasks I've started to update the OPF's current development guidelines, and added some guidance on the OPF’s GitHub policy. This includes standard practises that should be adopted by all OPF GitHub projects. The main concerns for new projects are:

  • create a descriptive (preferably GitHub markdown) README file.

  • clearly state the license terms of the project in a LICENSE file.

  • create a small YAML file listing some basic project metadata.

  • Adding this information makes it easy for somebody to find out what the project does, if they have permission to use it, and contact somebody if they have problems.

I’ve also written a little code that uses the GitHub API to create a web page that gives an overview of the OPF’s GitHub projects, providing warnings where projects don’t follow the OPF’s GitHub policy.  The generated page can be found here and is currently updated once a day.

I’m now working on guidelines for using Travis-CI, the online continuous integration service, and hosting binary packages on BinTray.  As I complete new sections I’ll also create a blog post giving a few more details. A recent OPF webinar tries to give the full picture, the slides are available on the Wiki.

I’ll wrap up this post by saying that I’m happy to take further suggestions, and answer questions, just drop me an email or IM me.  I’m happy to provide direct assistance to members who require it. It’s also nice to meet members in person, I’ll be attending all OPF events where possible, starting with the Hackathon in Copenhagen next week.  Oh, and I promise to blog a little more often……

By Carl Wilson, posted in Carl Wilson's Blog

8th May 2013  9:12 AM  10566 Reads  No comments

Comments

There are no comments on this post.


Leave a comment