Eddie talks about digress.it and JISCPress

It’s long, it’s a bit rough, but if you’re interested in the development of CommentPress, digress.it and a major part of the JISCPress project, you might want to set an hour aside…

Questions

  1. Can you tell us a bit about CommentPress and why the move to digress.it? (00:10)
  2. What design decisions have you made for digress.it? Is there anything that other developers should be aware of? (06:00)
  3. What single area of work on the JISCPress Project has been the most time-consuming (and therefore expensive)? (10:45)
  4. What’s been the biggest challenge for you on the JISCPress Project? (20:40)
  5. Paragraph-level trackbacks and remote embedding of paragraphs which also provided a trackback, were two requirements we kept pushing for. What problems still remain with these features? (23:50)
  6. What software tools or productivity methods do you use and how do you use them? (34:40)
  7. What was the most important thing that brought value to your work? (52:40)
  8. What’s the future of digress.it? How will it be sustained now the JISCPress project has finished? (55:16)
  9. Any more plans for digress.it? (01:02:15)
  10. You’ve started writing a digress.it server, right? (01:04:56)

Eddie Tejeda talks about digress.it and JISCPress from University of Lincoln on Vimeo.

Working remotely as a team

One of the things that I wanted to get a feel for during this project was how the university might successfully apply for and work on rapid innovation projects while not actually having development staff of our own. We have staff in ICT and Marketing who work on the corporate web and online services, such as Blackboard and Sharepoint. There are programmers in the School of Computing, too, who have their own research projects on the go, but there is no ‘development team’ who might be approached to work on JISCRI type projects. I am an adequate Linux SysAdmin, but am no ‘developer’. I can’t write a line of code.

The four members of the JISCPress team are:

Joss Winn (Staff, University of Lincoln)

Tony Hirst (Staff, Open University)

Alex Bilbie (Student, University of Lincoln)

Eddie Tejeda (Freelance developer, Visudo, San Francisco)

Project Methodology?

I wrote a bit about project methodology at the start of the project. The emphasis from JISC on using an ‘agile methodology’ just didn’t seem to fit the structure of our Team. All the agile methodologies I knew of emphasised the importance of working closely, sometimes even in pairs, and seemed designed for tightly focused, customer orientated projects with regular iterations around sprints of development. There was no way that I was going to be able to organise Tony, Eddie and Alex around regular sprints and had I tried to crack the whip, I think I would have received far less co-operation from them than I did. As it turned out, the team never actually met in the same room (err, pub…) until the JISC CETIS Conference earlier this month. On a couple of occasions during the summer, Alex worked in my office, but it wasn’t especially productive. It was clear that he was much more comfortable working at home. While Eddie was over for the CETIS conference (he paid his own way here, I want to add!), he came to Lincoln and worked for a day in the office with me. It was a productive day and I could see how teams working together like that could be highly productive both in the development of ideas and code but it wasn’t unlike how Eddie and I would work together virtually.

The other significant contributing factor to the way we worked was the type of development we were doing. Again, agile methodologies seem designed around creating a user-led product. There’s an expectation that the development team are working for a client who is embedded in the decision making process for the project. The client ‘owns’ the project and they ultimately own the code, too.

JISCPress didn’t have this type of client and we weren’t solely focused on the writing of new code either. The project was as much about taking existing code and piecing it together in a fruitful way, developing what we’d already pieced together with WriteToReply. We started with the WordPress Multi-User platform and CommentPress. We looked at some other existing WordPress plugins for working with Open Calais and creating relationships between content and also created a configuration file for Triplify and a plugin to publish data to the Talis Platform. We bootstrapped a complete rewrite of CommentPress, called digress.it and Alex wrote plugins for making WPMU work with OpenCalais and Triplify.

IPR

The University of Lincoln has no interest in ‘owning’ the code (no-one here would maintain it), JISC have no interest in owning the code (no-one there would maintain it) and the code is completely reliant on other open source software and APIs which we don’t maintain either. I was advised by OSS Watch to ensure that the code we funded was, wherever possible, copyright University of Lincoln, but I’ve ignored that advice. I just don’t see who it would benefit. In order to make the work interesting and sustainable, we needed Eddie and Alex to have a vested interest in the code they were writing. Eddie’s work on CommentPress was already credited to him and Jesse Wilbur and licensed under the GPL3. There was no advantage in the University of Lincoln claiming copyright in the digress.it code we were funding and I’m sure that had we insisted on this, Eddie wouldn’t have worked for us. We could have claimed copyright for the code that Alex has written, but as I said, no-one here will maintain it, so I think it’s better to encourage Alex to remain the copyright holder in the hope that he might maintain it for a while. There is no ££ value in WordPress plugin code. There’s only value in providing services around the code and Alex is the person best suited to do that, not the University.

How we actually worked together

My original intention was that we’d work together in public on IRC. Tony and I had started doing this on WriteToReply and thought we’d just continue the weekly meetings we were having. This happened once at the start of the project, but after that, we all just used Google Talk. The reason for this is simple: we all use it anyway. Eddie and I work with GMail open and rather than firing up another application just to ask a quick question, we used GTalk. It allowed us to see when we were online and effortlessly kept a log of everything we were saying. Alex and Tony also seemed to prefer to use it, too. Because it was attached to our personal email addresses, rather than work addresses, it also meant that we were available after 5pm and over the weekends. The convenience of using GTalk meant that on many occasions, I’d be contacted by Eddie as I was going to bed and end up spending late nights testing his latest code revisions and feeding back comments via GTalk. Had we relied on other tools, I wouldn’t have been in the habit of using them at home and consequently Eddie and I would have chatted far less than we did.

Our ‘office’ consisted of the Google Code svn repository and Google Talk. Eddie would check code in, I’d be waiting on the jiscpress.org server to check it out and then we’d chat about it over Google Talk. Anything that required time to fix, was added to the list of Issues. Alex and I worked differently. He’d usually come to my office on campus and show me what he’d done. I preferred to work over svn and Alex taught himself how to use it, but we never worked in real-time over svn as Eddie and I do.

Tony’s role was always one of provocateur and champion for the project. A lot of the best ideas (and hardest to implement) originated with Tony and then I would try to push them into Eddie’s list of tasks, which were hosted on the digress.it Google Code site.

Working with students

I think we’ve been really lucky to have Alex on the team. In the Centre for Educational Research and Development, where I work, we’re keen to work with and undertake research with students and it seemed like a natural extension of this  to be working with Alex. The project was nicely timed over the summer holidays, too, so Alex had quite a bit of time to spare during July – September. Noticeably, when the semester started again, he was very pushed for time partly because I’d found him other paying projects to work on and regrettably I ended up competing for his time! I should add that both Eddie and Alex worked more hours than they were actually paid for – not unusual when working in education, but from my point of view, it meant I was juggling a lot of good will at times.

Alex also came to the JISCRI and CETIS conferences where he seemed to really get a lot out of meeting other developers and talking about the work he has been doing on the project. I think all of us would say that the project has been an opportunity to learn from each other and hopefully we’ve documented the useful bits on this blog for others to learn from too. Eddie talks about his work for the project in a video interview I made with him. I’ll link to it from here when it’s ready.

Who were our users?

Agile methodologies put a lot of emphasis on the user and their stories. We didn’t arrange for a distinct set of users to feed back to the project. The main Stakeholders for the project were JISC and the JISC community, not Lincoln staff and students, so we needed to engage them as much as possible. We had already done this to a certain degree through WriteToReply and had republished the JISCRI call specifically to see how the community might use the platform. During the project, JISC launched their draft Strategy and a consultation on the Google Book Settlement, both of which used early versions of the digress.it code we were were developing. On a few occasions, I pointed people via Twitter and the blog to our UserVoice site, but no-one offered anything this way. Tony acted as an uber-user, looking at the platform from the point of view of a developer/mashup-artist and consequently fed back lots of thoughts for how it could be improved. Tony and I have also spent hours and hours publishing documents via WriteToReply and we’re acutely aware of the issues that publishing users might face. We also gained a lot of users following the launch of digress.it and it was embraced by the WordPress community (931 downloads and counting) as well as people signing up to Eddie’s site http://digress.it A mailing list specifically for digress.it was set up and people would feedback issues and requests that way. We also have a public mailing list for the JISCPress project as a whole. It has a few people lurking on it, but has not been a particularly effective method of communication. Perhaps it will be if people pick up the work we’ve done and try to set up their own version of JISCPress, as I hope they will do. As a public open source project, we pursued our original ideas in public and as the code was released, waited for users to feed back to us. Alex, too, got feedback in this way for his OpenCalais plugin and was made changes to his code based on a suggestion from another developer who is using it.

Misc.

A couple of things I didn’t plan for when working with Alex and Eddie were payroll related. Customs and Excise have told us that we have to pay VAT on Eddie’s invoices.  Fair enough. It didn’t occur to me because he doesn’t reside in the UK, but it makes sense. I learned a lesson and it didn’t affect the budget because the exchange rate improved in our favour over the course of the project and what we saved there, we spent on VAT.

Alex began as a freelancer with the intention of invoicing the project for his work at the agreed amount, but the university said it would be easier for Alex if he was put on the payroll and then his tax and NI would be dealt with. It affected the project by adding about £30 in NI contributions to the total amount we’d agreed – good value, I think. One less set of invoices that I had to deal with.

Did it work?

As I said at the top of this post, one of the benefits for me and the University of Lincoln, was to see how effectively we could run a development project in this way. It’s likely that any development project I get involved in will be based on existing open source software that has an existing community of developers and users, just as WordPress does. I’m just not interested in re-inventing the wheel on something completely new. I prefer to contribute rather than invent. In this respect, I feel like it’s been a success. Within a few days, we’ll have the prototype we set out to create and within a week or two, it will be documented so that anyone should be able to pick JISCPress up and make it their own. JISC have seen the benefits of using it on three documents so far and in one shape or another, I think they’ll continue to use it. We’ve shared our ideas around the project widely, both on this blog and the other sites we use (see sidebar) and have discussed and demonstrated our work at two conferences. digress.it is now a well-regarded WordPress plugin with a growing number of users. Recently, Cornell University have employed Eddie to continue to develop digress.it for a project they are running with the Whitehouse. Through the JISCPress project, JISC have directly contributed to the work Cornell are doing. Likewise, the New York Public Library also want Eddie to develop digress.it for them, so I’m confident that this part of our work will be maintained and fed back into the core tree of the code for everyone to benefit from.

WriteToReply has benefited of course. We’ve been able to spend time thinking about and working on ‘stuff’ which we intend to use on http://writetoreply.org Recently Eduserv offered to help us with hosting WriteToReply which has encouraged Tony and I to keep pursuing our interests in document publishing and public engagement on the web. I hope that we can work with Eduserv over the coming months and pass on what we know about WordPress hosting.

Finally, based on the work we’ve done on JISCPress with Triplify and WPMU, I plan to apply for funding from Talis to develop a ‘wordpress.com for OPACs’. It sounds ambitious, but a lot of the work has already been done on this and the Scriblio project and I think we can show it is a viable idea. You can read more about what we have in mind, here.