Bringing Things Together

Archive for the ‘open access’ Category

Bug Watches

Posted by Greg on June 15, 2008

As a part-time bug triager, I’m always curious of the new tools out there that enable people to work better and more efficiently.  One such new project, which I think has some real potential, is Stephan Hermann‘s Leonov project.

Another thing which I just read in my news reader was the fact that Luca Nussbaum added a functionality to Debian’s package overview pages which lets maintainers see what version of the package is in Ubuntu and how many bugs are reported against it in Launchpad.  This seems like a great idea and could even be expanded upon for better results.

My thought process:

A. Launchpad’s ability to watch other bug trackers for the same bug greatly improves the ability of developers to find and fix bugs.

A.1. People really like that ability.

B. Launchpad is only able to do that in a one-way direction (it can’t tell the Debian BTS that it’s bug has been marked “Fix Committed”)

B.1. Putting all of the work on the dev’s/triagers to then go back upstream and report it for every bug is a laudable goal, but as we all know, time is precious for everyone.

C. The ability to get bug data from LP and use it for enabling productivity is there, albeit a little “hacky” (screen scrapping is never fun).

D. Wouldn’t it be cool if other Bug Trackers could watch LP in the same way it watches them?

It seems to me, from both Lucas’ and Stephan’s efforts that doing D is possible right now.  Yes, it would be a ton more easy if Lucas’ and Stephan’s concerns were addressed (text/XML export etc).

I know the Launchpad developers are working right now to implement support for reporting back to other bug trackers certain information but I’m not sure of its progress.

Some Blueprints which might be related but I can not read (they are private): Bugs Remote API and Remote Launchpad Python Library (if you know of any other blueprints or bugs with more information, post them in the comments, please).

Does anyone know of any other bug trackers which are actively working on or at least discussing the ability to grab data from LP (or other BTS)  about certain bugs?

Posted in Freedom, open access, Sharing, Ubuntu, Uncategorized | 3 Comments »

Since it hasn’t been talked about enough already…

Posted by Greg on March 24, 2008

So, why should LaunchPad (Malone) be open sourced?*

I’m not going to say because other groups need to use the bug tracking/code hosting/question answering/multi-project-resource unifying features. No, I do believe that it wouldn’t make much sense for there to be multiple Launchpads out there dealing with bugs/code/etc (maybe a little of sense, but not much).

That market is already taken by launchpad.net and others (bugzilla, trac, savannah, et. al.)

Ok, so what market am I looking at? Scholarly communication <BORING!>

Not really boring actually. If you haven’t been paying attention to the scholarly communication world lately, let me tell you, a lot is changing. University libraries are spending more and more money every year on electronic journals. The rate of increase for the same product is higher than that of inflation, for a product which doesn’t improve (can we say monopoly/oligopoly?). In response many institutions (university libraries) are beginning to provide competing services. Full disclosure, my current employer is the Scholarly Publishing Office at the University of Michigan where we publish scholarly journals in an online and Open Access fashion. So, we are providing an alternative to the current commercial publisher vendor lock-in.

What does this have to do with LaunchPad and Open Source Software? Well, we are now in a global situation where there are many many many many open access journals and publications out there. There are some services out there than can help you navigate them, like the Directory of Open Access Journals. But, that service only indexes Open Access journals. Plus, there are now these things called Institutional Repositories, which are collections of preprints and articles and data from the “scholars” in a given “institution” (university, research lab, etc).

Then you have the commercial vendors. They don’t like people looking at their stuff, they don’t play nice with others unless they think they will lose money if they don’t. Libraries are getting better and better at letting their patrons search both sets of journals in one place, but the interface ALWAYS is hideous and creates MANY hoops the user has to jump through. In a word, it is LAME.

I haven’t answered what LP has to do with this yet. I’m getting there, I promise.

What does LaunchPad do really well? Linking various bugtrackers so that people can work together more efficiently to solve problems, right? That was the whole goal of Launchpad, otherwise Ubuntu would have stayed with bugzilla. What is the analogue for the scholarly publishing/communication world? You have those many distinct collections of articles (Open Access journals, Institutional Repositories, and commercial vendors) that do not talk to each other, ever. Yes, there are groups out there trying to improve this situation like the Open Archives Initiative where they are setting metadata standards and standards for transferring that information to others. That is a great thing, but it is only a start.

<The Answer, Finally> If we created a LaunchPad for scholarly works, we could solve many of the beginning access issues associated with this crappy situation. Here’s the idea:

Think of a bug, that is the article in this case. The article (bug) can have a published status like draft version or published in a journal (New, Incomplete, Fix Committed). But for it to even be an article in this Scholar’s LP it needs to have a reference to where it is, physically. So instead of a bug originating in LP and then being linked to other trackers as time goes on, the article needs to have an initial link to some place (OA journal, IR, or Comm. Vendor) using some standard like Digital Object Identifier or Handle.net (which assigns a unique id to object online that can point to any address, so the changing of URLs won’t effect findability).

Then, this article (bug) can also have different versions linked to it. So, example: I publish an article in a prestigious journal, Nature, and I’m proud of it. So, I go to the Scholar’s LP and submit a new article. I give it the DOI or handle.net id and it automagically retrieves the metadata from the article’s current place of residence (that is if the provide it, if it is a commercial vendor, I might have to fill it in myself). Then it shows up as a new article in the system. My advisor, who thinks the work I did was cool, thinks that my previous drafts before publication are also pretty good. Since the version in Nature is not available to everyone for free, he links the preprint version that resides in my University’s Institutional Repository to my article. That is just like linking to an upstream bug in LP.

Of course, all the metadata is editable and updatable with information like author(s), publication data, place, copyright status (license), etc etc. Plus, if we wanted, we could limit certain metadata elements (like copyright status) to only the article’s author(s), we can do that by verifying emails with respect to what is in the actual article’s author list.

This Scholar’s LP could provide a wonderful unified interface so that “scholars” (define that however you want) can navigate this crazy mess of publishing easily (or at least easier). The “killer app” part of this is the ability to link a published article which is under crappy copyright restrictions to other versions which are available for everyone via institutional repositories or other places, in one place.

There are plenty of fancy cool things which could be done with this model, and I will talk about those later. One example is automatically linking to works cited to another Scholar’s LP or to an external link. But for now, I just wanted to get this idea out there and see if anyone has any comments.

* yes, you are right, we don’t need LaunchPad to be opensourced to do this, it was just a way to get you to read this, sorry.

Posted in Freedom, open access, School, spo, Ubuntu | 10 Comments »

Gots me a Job, ‘cuz I’m SMRT!

Posted by Greg on January 16, 2008

Yes, I have a job now. I currently work for the Scholarly Publishing Office at the University of Michigan Libraries.

Right now it is a pretty mundane job. I convert incoming articles to a standard format (there is a little bit more to it than just Open -> Save As). When I am done with the conversion, they are published! Online! Usually Open Access! Woot!

Yeah, that is the cool part. The SPO does a really cool service. It provides electronic publishing for peer-reviewed scholarly journals, and most times those journals publish as open access. If you don’t know what Open Access is, well, where have you been? It is the Next Big Thing(TM)(R)! Really, if you don’t, read some stuff that Peter Suber has written, for instance his Open Access Overview and his log.

Now I just need to compete with Kathleen (a co-worker) for space in the office!

Posted in open access, spo | Leave a Comment »