Tag Archives: bugs

Sowing the seeds

Today I devoted an unusually large amount of time doing free user support for BuddyPress and WordPress (in IRC, over email, through some Trac tickets, and on WordPress StackExchange, the latter of which I’ve been experimenting with for the first time, and I find pretty cool). I say “unusually large” because while I used to do a lot of this sort of thing, it now falls to the bottom of my list of priorities – I do paid work, and when I’m not doing that I do free software development, and when I’m not doing that I try to get the hell away from my computer. As one of the leaders of the BuddyPress project, I usually justify this balance to myself by saying: There are lots of people who can provide user support for this software as well as I can, but there are few who can do productive development for it like I can, so my time is better spent developing. Generally, I think this is a pretty good argument. But I’m glad that days like today come along occasionally, because they remind me of some basic things about the nature of the community around a piece of free software that you can forget when your head is buried too deep in the codebase.

As an aside, I should note that I use the word ‘community’ in a measured way. The word is often overapplied, as if calling a bunch of people working on similar things “the WordPress community” or “the Digital Humanities community” or “the CUNY community” will, in a feat of performative metamorphosis (like how the Queen’s saying “I dub thee Sir Boone” would ipso facto make me a knight), bring into being the thing it purports to describe. Terminological misgivings to one side, there is an undeniable sense in which the work that we do – and by “we” here I mean specifically free software developers, though the point is quite a bit more general than that – is done in a community, or at least (more formally) a network, insofar as those who work on a common piece of free software never really work in isolation from one another. The development process that underlies these software projects depends on the existence of feedback loops, from the end user to the administrator of the installation to the community leaders to the developers themselves, in the form of bug reports, software patches, feature suggestions, support requests, blog posts, and so on.

These feedback loops are not unique to free software development; they’re not even unique to software. But in free software circles the loops are perhaps uniquely malleable, and the distinctions between user and developer uniquely permeable. Each user is a potential contributor, be it through code or advocacy. But the potential is not realized automatically. It’s obvious enough that users who hate using the software and developers whose patches are ignored will never become part of the community. More interesting is the case where a newbie approaches the community with enthusiasm and skill, but where their offerings are not nurtured and so never become real contributions.

I think this happens more than we would care to admit, and I am happy to take my share of the blame. As a developer, I become emotionally attached to the project, and as a result I sometimes interpret criticism as a personal attack. The parts of development that are least exciting – hunting down and fixing the obscure bugs that affect only a small number of users but, for those users, are ruinous – these make me defensive and sometimes angry, as they take my attention away from the more generative work I’d rather be doing. I value my time so highly that I occasionally get annoyed when someone requests some of that time to answer a “simple” question. In each instance, my attitude as a developer and leader of the project could have the effect of chilling what might otherwise have been a fruitful engagement.

Taking the time to do some “support” is the ideal way to fight these tendencies. People ask questions about the software, contribute patches, suggest improvements, etc, because they like the software and want to use it. These people are friends of the project, and should not be treated as enemies. Taking the time to work directly with users is a way of closing the feedback circuit, of sowing the seeds of future collaboration and contribution. If one out of five people recommends the software to someone else, and one out of a hundred contributes back to the software in the form of documentation or code or advocacy, that’s fruitful enough to make the engagement worthwhile.

Blackboard hack: Merging classes from multiple pages

Blackboard has a feature called Course Merge that lets instructors teaching more than one section of a course merge the sections into a single roster and course space. It turns out, though, that in Blackboard 8, if a professor has more than 25 or so courses alive in the system (which can easily happen when lab subsections of a large lecture course are listed separately), the Merge tool breaks. In particular, the list of courses to select as parent/child courses of the merge gets broken up into multiple pages. You’ve got to check the boxes next to the courses you want merged and hit Submit to complete the process. But (O! miracle of UI design) the Submit button only appears on the last page, making it impossible to merge courses on any pages but the very last one.

I’ll pause to say that this bug means that the people who most need to merge their courses – the ones who have big classes with lots of subsections – are the most likely to be unable to do so. Yikes.

So here’s an ugly but functional workaround. I’ve cobbled together the information in the HTML form element on the final step of the merge process into a single form. The value attributes in the input tags have be replaced with the unique identifiers for the classes to be merged, which you can find by viewing the source of the course list. You’ll also need to change the URL in the form tag to point to the absolute location of your Blackboard installation. Save the file to your local disk. As long as the HTML file is run in a browser that is logged into Blackboard as a user with the permission to do the merge, selecting the radio button and clicking submit on the local file will successfully submit the form and complete the merge.

Here’s the code:

 <form name="CourseCreateForm" method="post" action="/webapps/bbgs-coursemergetool-bb_bb60/setupMergedCourse.do">

<!-- The following two lines are the courses to be merged. Replace the values with your course identifiers -->

<!-- The following line identifies the "target" or "parent" course into which the others will be merged -->