Category: work

The brief guide to MSCD 5

Luis Villa1 Comment

My primary goal when trying to improve a contract’s drafting is not “plain english”. The goal is simplicity, clarity, and consistency, because complexity is a source of errors. As a pleasant side-effect, contracts drafted with rigorous attention to consistency and clarity are generally shorter, and almost always much easier to read.

Ken Adam’s Manual of Style for Contract Drafting has helped me immeasurably in reaching that primary goal, both by teaching me habits of mind and by being a reference for better linguistic structures.

But it’s also hefty.

So I prepared this mini-guide to MSCD for an outside counsel: it’s what I recommend first-timers read, skim, and skip. I share it here in hopes it may be useful for others.

All section references are to the Fifth Edition, but at least at the chapter level most should apply to earlier versions as well.

MSCD core concepts

These are the most impactful sections of MSCD.

Introduction

If you are confused about why I recommend the book, read “About this manual”, “Traditional Contract Language is Dysfunctional”, and “Excuses for Sticking With Traditional Contract Language”. Skip or skim the rest.

Ch. 1: Characteristics of Optimal Contract Language; Ch. 17: Drafting as Writing

These can be skimmed, since in some sense most of it will be obvious to anyone who has given any thought to better contract language. But both are good, and brief, and explain (in part) why traditional drafting is so bad. So if you find yourself confused by something in other chapters, come back to these two—they may help explain things.

While reading, I particularly recommend these sections, which have had the biggest impact on my personal drafting style and are, in my experience, the biggest red flags for errors that stem from bad “traditional” drafting:

  • “Contract Language Shouldn’t Be Legalistic” (1.7-1.28)
  • “Contract Language Should Express Ideas without Redundancy” (1.35-1.56)
  • “Contract Language Should Be Consistent” (1.57-1.60)

Ch. 2: Front of the Contract; Ch. 5: Back of the Contract

In my practice area, the front and back matter are not usually the source of critical errors, so I do not religiously follow these sections. However, I find that attention to detail on these topics is both a good introduction to MSCD’s style of thinking, and (when I do them in a contract) help put me in a rigorous frame of mind for the rest of the document. So these chapters are worth skimming and then consistently using as a reference.

If you are pressed for time, 95% of chapter 2’s value can be obtained by:

  • reading 2.129-2.150, Recitals. Once you get used to improving the drafting of the recitals, it sets a good tone for the rest of the document.
  • reading 2.159-2.164, Wording of the lead-in. Understanding, and sticking with, Ken’s recommended use of “agree” here sets up Ch. 3’s critical “categories of contract language”.
  • skimming Samples 1 and 2, and Appendix A’s front matter, to get the flavor of the kinds of improvements that can be made to most contracts.

Ch. 5 is similar—just skim the back matter of Appendix A, then refer to the samples in the chapter for models.

Ch. 3: Categories of Contract Language

If you only read one chapter, read this one.

This chapter is the core of MSCD’s style of thought: the core of clear and correct drafting is that different parts of contracts do different things, and you should rigorous using specific language to implement each of those things.

You can do a lot to improve a contract simply by looking at each table in this section, reading the relevant section to understand the tables, and cleaning up every reference in a contract from the table’s disfavored language to the favored language. Doing this consistently across the entire contract will force rewrites that leave the resulting language much clearer, more precise, and more accurate.

Two words discussed in this chapter are particular warning signs for me when I see them misused in a contract: “shall” (particularly 3.115-3.132 and Table 2) and “agrees” (3.27-3.30). Again, simply cleaning these up is a great way to do a “first pass” edit of a document—doing this helps you think about what each clause of a contract is actually trying to do, and often leads to more correct, more readable drafting.

Ch. 13: Selected Usages

This is a reference section, not something to read end-to-end. But it’s invaluable. When you find something that “feels wrong” in a contract, you’ll often be able to come to this section and find a much better, clearer way to state it. You may have to rewrite things substantially, but you’ll have a more logically consistent, consistent, correct, clearly-readable document when you’re done.

I suggest skimming the table of contents, and then reading a few examples to give you the flavor of it. A couple of my favorites:

  • For the Avoidance of Doubt: 13.312-319
  • “Including”—long, but a great analysis of the complexity and nuances of a single word: 13.359-407

Ch. 14: Numbers

Read the brief part on “Words or Digits” to learn why there should be zero(o) instances of number(numeral). Skip or skim the rest.

Advanced Drafting to Reduce Ambiguity

These chapters are useful primarily for the most complex drafting problems. I tend to do a “first pass” edit based on the “core concepts” chapters I identified previously.

If that first edit pass identifies a particularly complex/problematic section, then the concepts in these chapters can be quite helpful in making the challenging contract sections more correct.

  • Ch. 7: Sources of Uncertain Meaning: 95% of the value of this chapter is one concept: the distinction between ambiguity (bad, unintentional, should be eliminated) and vagueness (intentional, may be strategic, must be deployed carefully).
  • Ch. 11: Ambiguity of the Part v. The Whole: most useful in commercial contracts where it’s important to be precise about what is being sold (or not).
  • Ch. 12: Syntactic Ambiguity: a collection of techniques that are frequently useful in deconstructing, and then reconstructing, extremely long or complex sentences.

Interesting but not useful (to me/my practice)

These chapters are intellectually interesting but I have not found them to be particularly high-impact on my practice. Might be different for your practice!

Ch. 6: Defined Terms

I do not find definitions to be a significant source of problems, as a practical matter, so don’t find this chapter hugely valuable.

However, there are a few sections that cover errors that I find frequently, so are more useful than the rest:

  • “Be Consistent” (6.8-6.13)
  • “stuffed definitions” (6.49-58)
  • Mistakes: 6.110-6.122

I don’t usually follow the advice of “where to put the definition section” (6.96-6.98), but I think it’s at least worth trying in many documents.

Other interesting-but-less-useful-to-me chapters

These chapters are all interesting for drafting nerds, and may be relevant to some practices, but not frequently an issue for me.

  • Ch. 8: Reasonable Efforts
  • Ch. 9: Materiality
  • Ch. 18: Amendments; Ch. 19 Letter Agreements

Neither interesting nor useful (to me/my practice)

I mostly ignore these—they’re not wrong but the bang-for-buck of rewriting with them in mind is pretty low, in my experience.

Ch. 4: Layout; Ch. 16 Typography

I tend to rely on Butterick’s Typography for Lawyers for these topics.

Ch. 10: Time

Suspect most relevant for certain types of commercial contracts where extreme specificity about time (delivery, etc.) are common sources of disputes.

Ch. 15: Internal rules of interpretation

Have never seen one of these in the wild that I can recall.

Writing elsewhere; the pain of moving platforms

Luis Villa1 Comment

I’ve been doing a lot of writing elsewhere of late. Some links:

  • I’ve written a fair amount in the past year for the Tidelift blog, most recently on the EU’s Cyber Resiliency Act and what it might mean for open source.
  • I wrote last week at opensource.com; the latest in a now multi-year series on board candidates in elections for the Open Source Initiative.
  • I have a newsletter on the intersection of open and machine learning at openml.fyi. It is fun!
  • I’ve moved to the fediverse for most of my social media—I’m social.coop/@luis_in_brief (and you can subscribe to this blog via the fediverse at @lu.is/@admin).

I don’t love (mostly) leaving Twitter; as I’ve said a few times, the exposure to different people there helped make me a better person. But one of my primary political concerns is the rise of fascism in the US, and that absolutely includes Elon and the people who enable him. I can’t quit cold-turkey; unfortunately, too many things I care about (or need to follow for work) haven’t left. But I can at least sleep well.

Wikimania 2015 – random thoughts and observations

Luis Villa5 Comments
Image

Random thoughts from Wikimania, 2015 edition (2013, 2014):

"Wikimania 2015 Reception at Laboratorio Arte Alameda - 02" by Jarek Tuszynski, under CC BY 4.0
“Wikimania 2015 Reception at Laboratorio Arte Alameda – 02” by Jarek Tuszynski, under CC BY 4.0

  • Dancing: After five Wikimedia events (not counting WMF all-hands) I was finally dragged onto the dance floor on the last night. I’ll never be Garfield, but I had fun anyway. The amazing setting did not hurt.
  • Our hosts: The conference was excellently organized and run. I’ve never had Mexico City high on my list of “places I must see” but it moved up many spots after this trip.
  • First timers: I always enjoy talking to people who have never been to Wikimania before. They almost always seem to have enjoyed it, but of course the ones I talk to are typically the ones who are more outgoing and better equipped to enjoy things. I do hope we’re also being welcome to people who don’t already know folks, or who aren’t as outgoing.
  • Luis von Ahn: Good to chat briefly with my long-ago classmate. I thought the Q&A section of his talk was one of the best I’ve seen in a long time. There were both good questions and interesting answers, which is more rare than it should be.
  • Keynotes: I’d love to have one keynote slot each year for a contributor to talk about their work within the movement. Finding the right person would be a challenge, of course, as could language barriers, but it seems like it should be doable.
  • US English: I was corrected on my Americanisms and the occasional complexity of my sentence structure. It was a good reminder that even for fairly sophisticated speakers of English as a second language, California-English is not terribly clear. This is especially true when spoken. Verbose slides can help, which is a shame, since I usually prefer minimal slides. I will try to work on that in the future, and see how we can help other WMFers do the same.
  • Mobile: Really hope someday we can figure out how to make the schedule legible on a mobile device :) Good reminder we’ve got a long way to go there.
  • Community engagement: I enjoyed my departments “engage with” session, but I think next year we need to make it more interactive—probably with something like an introduction/overview followed by a World Cafe-style discussion. One thing we did right was to take questions on written cards. This helped indicate what the most important topics were (when questions were repeated), avoided the problem of lecture-by-question, and opened the floor to people who might otherwise be intimidated because of language barriers or personality. Our booth was also excellent and I’m excited to see some of the stories that came out of it.
  • Technology and culture: After talking about how we’d used cards to change the atmosphere of a talk, someone deliberately provoked me: shouldn’t we address on-wiki cultural issues the same way, by changing the “technology” used for discussion? I agree that technology can help improve things, and we should think about it more than we do (e.g.) but ultimately it can only be part of the solution – our most difficult problems will definitely require work on culture as well as interfaces. (Surprisingly, my 2009 post on this topic holds up pretty well.)
  • Who is this for? I’ve always felt there was some tension around whether the conference is for “us” or for the public, but never had language for it. An older gentleman who I spoke with for a while finally gave me the right term: is it an annual meeting or is it a public conference? Nothing I saw here changed my position, which is that it is more annual meeting than public conference, at least until we get much better at turning new users into long-term users.
  • Esino Lario looks like it will be a lot of fun. I strongly support the organizing committee’s decision to focus less on brief talks and more on longer, more interactive conversations. That is clearly the best use of our limited time together. I’m also excited that they’re looking into blind submissions (which I suggested in my Wikimania post from last year).
  • Being an exec: I saw exactly one regular talk that was not by my department, though I did have lots and lots of conversations. I’m still not sure how I feel about this tradeoff, but I know it will become even harder if we truly do transition to a model with more workshops/conversations and fewer lectures, since those will be both more valuable and more time-consuming/less flexible.
  • Some day: I wrote most of this post in the Mexico City airport, and saw that there are flights from there to La Habana. I hope someday we can do a Wikimania there.

What tools are changing our world next?

Luis Villa3 Comments
Image

Quick brain dump after a bike ride home: free software took a huge leap in the late 90s and early 00s in large part because of non-ideological advantages that the rest of the world is now competing with or surpassing:

HDR automatically created from old pictures of Muir Woods by Google Photos.
HDR automatically created by Google Photos from my old pictures of Muir Woods. Not perfect, but better than I ever bothered to do!

  • Collaboration tools: Because we got to the ‘net first, our tools for collaborating with each other were simply better than what proprietary developers were doing: cvs, mailman, wiki, etc., were all better than the silo’d old-school tools. Modern best-of-breed collaboration tools have all learned from what we did and added proprietary sauce on top: github, slack, Google Docs, etc. So our tools that are now (at best) as productive as our proprietary counterparts, and sometimes less productive but ideologically agreeable.
  • Release processes: “Release early/release often” made us better partners for our users. We’re now actively behind here: compare how often a mobile app or web user gets updates, exactly as the author intended, relative to a user of a modern Linux distro.
  • Zero cost: We did things for no (direct) cost by subsidizing our work through college, startups, or consulting gigs; now everyone has a subsidize-by-selling-something-else model (usually advertising, though sometimes freemium). Again, advantage (mostly?) lost.
  • Knowing our users: We knew a lot about our users, because we were our biggest users, and we talked to other users a lot; this was more effective than what passed for software design in the late 90s. This has been eclipsed by extensive a/b testing throughout the industry, and (to a lesser extent) by more extensive usage of direct user testing and design-thinking.

None of these are terribly original observations – all of these have been remarked on before. But after playing some with Google Photos this weekend, I’m ready to add another one to the list:

Worth asking what your project is doing that could be radically changed if your competitors get access to new technology. For example, for Wikipedia:

  • Collaborating: Wiki was best-of-breed (or close); it isn’t anymore. Visual Editor helps get editing back to par, but the social aspect of collaboration is still lacking relative to the expectations of many users.
  • Knowledge creation: big groups of humans, working together wiki-style, is the state of the art for creating useful, non-BS knowledge at scale. With the aforementioned machine learning, I suspect this will no longer the case in a (growing) number of domains.

I’m sure there are others…

Understanding Wikimedia, or, the Heavy Metal Umlaut, one decade on

Luis Villa34 Comments
Image

It has been nearly a full decade since Jon Udell’s classic screencast about Wikipedia’s article on the Heavy Metal Umlaut (current text; Jan. 2005). In this post, written for Paul Jones’ “living and working online” class, I’d like to use the last decade’s changes to the article to illustrate some points about the modern Wikipedia. ((I still haven’t found a decent screencasting tool that I like, so I won’t do proper homage to the original—sorry Jon!))

Measuring change

At the end of 2004, the article had been edited 294 times. As we approach the end of 2014, it has now been edited 1,908 times by 1,174 editors. ((Numbers courtesy X’s edit counter.))

This graph shows the number of edits by year – the blue bar is the overall number of edits in each year; the dotted line is the overall length of the article (which has remained roughly constant since a large pruning of band examples in 2007).

Edits-by-year

 

The dropoff in edits is not unusual — it reflects both a mature article (there isn’t that much more you can write about metal umlauts!) and an overall slowing in edits in English Wikipedia (from a peak of about 300,000 edits/day in 2007 to about 150,000 edits/day now). ((It is important, when looking at Wikipedia statistics, to distinguish between stats about Wikipedia in English, and Wikipedia globally — numbers and trends will differ vastly between the two.))

The overall edit count — 2000 edits, 1000 editors — can be hard to get your head around, especially if you write for a living. Implications include:

  • Style is hard. Getting this many authors on the same page, stylistically, is extremely difficult, and it shows in inconsistencies small and large. If not for the deeply acculturated Encyclopedic Style we all have in our heads, I suspect it would be borderline impossible.
  • Most people are good, most of the time. Something like 3% of edits are “reverted”; i.e., about 97% of edits are positive steps forward in some way, shape, or form, even if imperfect. This is, I think, perhaps the single most amazing fact to come out of the Wikimedia experiment. (We reflect and protect this behavior in one of our guidelines, where we recommend that all editors Assume Good Faith.)

The name change, tools, and norms

In December 2008, the article lost the “heavy” from its name and became, simply, “metal umlaut” (explanation, aka “edit summary“, highlighted in yellow):

Name change

A few take aways:

  • Talk pages: The screencast explained one key tool for understanding a Wikipedia article – the page history. This edit summary makes reference to another key tool – the talk page. Every Wikipedia article has a talk page, where people can discuss the article, propose changes, etc.. In this case, this user discussed the change (in November) and then made the change in December. If you’re reporting on an article for some reason, make sure to dig into the talk page to fully understand what is going on.
  • Sources: The user justifies the name change by reference to sources. You’ll find little reference to them in 2005, but by 2008, finding an old source using a different term is now sufficient rationale to rename the entire page. Relatedly…
  • Footnotes: In 2008, there was talk of sources, but still no footnotes. (Compare the story about Motley Crue in Germany in 2005 and now.) The emphasis on foonotes (and the ubiquitous “citation needed”) was still a growing thing. In fact, when Jon did his screencast in January 2005, the standardized/much-parodied way of saying “citation needed” did not yet exist, and would not until June of that year! (It is now used in a quarter of a million English Wikipedia pages.) Of course, the requirement to add footnotes (and our baroque way of doing so) may also explain some of the decline in editing in the graphs above.

Images, risk aversion, and boldness

Another highly visible change is to the Motörhead art, which was removed in November 2011 and replaced with a Mötley Crüe image in September 2013. The addition and removal present quite a contrast. The removal is explained like this:

remove File:Motorhead.jpg; no fair use rationale provided on the image description page as described at WP:NFCC content criteria 10c

This is clear as mud, combining legal issues (“no fair use rationale”) with Wikipedian jargon (“WP:NFCC content criteria 10c”). To translate it: the editor felt that the “non-free content” rules (abbreviated WP:NFCC) prohibited copyright content unless there was a strong explanation of why the content might be permitted under fair use.

This is both great, and sad: as a lawyer, I’m very happy that the community is pre-emptively trying to Do The Right Thing and take down content that could cause problems in the future. At the same time, it is sad that the editors involved did not try to provide the missing fair use rationale themselves. Worse, a rationale was added to the image shortly thereafter, but the image was never added back to the article.

So where did the new image come from? Simply:

boldly adding image to lead

“boldly” here links to another core guideline: “be bold”. Because we can always undo mistakes, as the original screencast showed about spam, it is best, on balance, to move forward quickly. This is in stark contrast to traditional publishing, which has to live with printed mistakes for a long time and so places heavy emphasis on Getting It Right The First Time.

In brief

There are a few other changes worth pointing out, even in a necessarily brief summary like this one.

  • Wikipedia as a reference: At one point, in discussing whether or not to use the phrase “heavy metal umlaut” instead of “metal umlaut”, an editor makes the point that Google has many search results for “heavy metal umlaut”, and another editor points out that all of those search results refer to Wikipedia. In other words, unlike in 2005, Wikipedia is now so popular, and so widely referenced, that editors must be careful not to (indirectly) be citing Wikipedia itself as the source of a fact. This is a good problem to have—but a challenge for careful authors nevertheless.
  • Bots: Careful readers of the revision history will note edits by “ClueBot NG“. Vandalism of the sort noted by Jon Udell has not gone away, but it now is often removed even faster with the aid of software tools developed by volunteers. This is part of a general trend towards software-assisted editing of the encyclopedia.NoSwagForYou
  • Translations: The left hand side of the article shows that it is in something like 14 languages, including a few that use umlauts unironically. This is not useful for this article, but for more important topics, it is always interesting to compare the perspective of authors in different languages.Languages

Other thoughts?

I look forward to discussing all of these with the class, and to any suggestions from more experienced Wikipedians for other lessons from this article that could be showcased, either in the class or (if I ever get to it) in a one-decade anniversary screencast. :)

My Wikimania 2014 talks

Luis Villa9 Comments
Image

Primarily what I did during Wikimania was chew on pens.

Discussing Fluid Lobbying at Wikimania 2014, by Sebastiaan ter Burg, under CC BY 2.0
Discussing Fluid Lobbying at Wikimania 2014, by Sebastiaan ter Burg, under CC BY 2.0

However, I also gave some talks.

The first one was on Creative Commons 4.0, with Kat Walsh. While targeted at Wikimedians, this may be of interest to others who want to learn about CC 4.0 as well.

Second one was on Open Source Hygiene, with Stephen LaPorte. This one is again Wikimedia-specific (and I’m afraid less useful without the speaker notes) but may be of interest to open source developers more generally.

The final one was on sharing; video is below (and I’ll share the slides once I figure out how best to embed the notes, which are pretty key to understanding the slides):

Slide embedding from Commons

Luis Villa12 Comments
Image

A friend of a friend asked this morning:

I suggested Wikimedia Commons, but it turns out she wanted something like Slideshare’s embedding. So here’s a test of how that works (timely, since soon Wikimanians will be uploading dozens of slide decks!)

This is what happens when you use the default Commons “Use this file on the web -> HTML/BBCode” option on a slide deck pdf:

Wikimedia Legal overview 2014-03-19

Not the worst outcome – clicking gets you to a clickable deck. No controls inline in the embed, though. And importantly nothing to show that it is clickable :/

Compare with the same deck, uploaded to Slideshare:

Some work to be done if we want to encourage people to upload to Commons and share later.

Update: a commenter points me at viewer.js, which conveniently includes a wordpress plugin! The plugin is slightly busted (I had to move some files around to get it to work in my install) but here’s a demo:

Update2: bugs are fixed upstream and in an upcoming 0.5.2 release of the plugin. Hooray!

I am the CADT; and advice on NEEDINFOing old bugs en masse

Luis Villa16 Comments
Image

[Attention conservation notice: probably not of interest to lawyers; this is about my previous life in software development.]

<a href="https://commons.wikimedia.org/wiki/File:MW_Bug_Squad_Barnstar.svg">Bugsquad barnstar, under MPL 1.1</a>
Bugsquad barnstar, under MPL 1.1

Someone recently mentioned JWZ’s old post on the CADT (Cascade of Attention Deficit Teecnagers) development model, and that finally has pushed me to say:

I am the CADT.

I did the bug closure that triggered Jamie’s rant, and I wrote the text he quotes in his blog post. ((Both had help from others, but it was eventually my decision.))

Jamie got some things right, and some things wrong. The main thing he got right is that it is entirely possible to get into a cycle where instead of seriously trying to fix bugs, you just do a rewrite and cross your fingers that it fixes old bugs. And yes, this can particularly happen when you’re young and writing code for fun, where the joy of a from-scratch rewrite can overwhelm some of your other good senses. Jamie also got right that I communicated the issue pretty poorly. Consider this post a belated explanation (as well as a reference for the next time I see someone refer to CADT).

But that wasn’t what GNOME was doing when Jamie complained about it, and I doubt it is actually something that happens very often in any project large enough to have a large bug tracking system (BTS). So what were we doing?

First, as Brendan Eich has pointed out, sometimes a rewrite really is a good idea. GNOME 2 was such a rewrite – not only was a lot of the old code a hairy mess, we decided (correctly) to radically revise the old UI. So in that sense, the rewrite was not a “CADT” decision – the core bugs being fixed were the kinds of bugs that could only be fixed with massive, non-incremental change, rather than “hey, we got bored with the old code”. (Immediately afterwards, GNOME switched to time-based releases, and stuck to that schedule for the better part of a decade, which should be further proof we weren’t cascading.)

This meant there were several thousand old bugs that had been filed against UIs that no longer existed, and often against code that no longer existed or had been radically rewritten. So you’ve got new code and old bugs. What do you do with the old bugs?

It is important to know that open bugs in a BTS are not free. Old bugs impose a cost on developers, because when they are trying to search relevant bugs, old bugs can make it harder to find the things they really should be working on. In the best case, this slows them down; in the worst case, it drives them to use other tools to track the work they want to do – making the BTS next to useless. This violates rule #1 of a BTS: it must be useful for developers, or else it all falls apart.

So why did we choose to reduce these costs by closing bugs filed against the old codebase as NEEDINFO (and asking people to reopen if they were still relevant) instead of re-testing and re-triaging them one-by-one, as Jamie would have suggested? A few reasons:

  • number of triagers v. number of bugs: there were, at the time, around a half-dozen active bug volunteers, and thousands of pre-GNOME 2 bugs. It was simply unlikely that we’d ever be able to review all the old bugs even if we did nothing else.
  • focus on new bugs: new bugs are where triagers and developers are much more likely to be relevant – those bugs are against fresh code; the original filer is much more likely to respond to clarifying questions; etc. So all else being equal, time spent on new bugs was going to be much better for the software than time spent on old bugs.
  • steady flow of new bugs: if you’ve got a small number of new bugs coming in, perhaps you split your time – but we had no shortage of new bugs, nor of motivated bug reporters. So we may have paid some cost (by demotivating some reporters) but our scarce resource (developers) greatly appreciated it.
  • relative burden: with thousands of open bugs from thousands of reporters, it made sense to ask old them to test their bug against the new code. Reviewing their old bugs was a small burden for each of them, once we distributed it.

So when isn’t it a good idea to close ask for more information about old bugs?

  • Great at keeping old bugs triaged/relevant: If you have a very small number of old bugs that haven’t been touched in a long time, then they aren’t putting much burden on developers.
  • Slow code turnover: If your development process is such that it is highly likely that old bugs are still relevant (e.g., core has remained mostly untouched for many years, or effective use of TDD has kept the number of accidental new bugs low) this might not be a good idea.
  • No triggering event: In GNOME, there was a big event, plus a new influx of triagers, that made it make sense to do radical change. I wouldn’t recommend this “just because” – it should go hand-in-hand with other large changes, like a major release or important policy changes that will make future triaging more effective.

Relatedly, the team practices mailing list has been discussing good practices for migrating bug tracking systems in the past few days, which has been interesting to follow. I don’t take a strong position on where Wikimedia’s bugzilla falls on this point – Mediawiki has a fairly stable core, and the volume of incoming bugs may make triage of old bugs more plausible. But everyone running a very large bugzilla for an active project should remember that this is a part of their toolkit.

Final(?) Wikimania 2013 idea and notes dump

Luis Villa6 Comments
Image

Luis at Victoria Peak, the morning after
Me at Victoria Peak, the day after Wikimania, with thanks to Coren.

More random, more-or-less stream-of-(un)consciousness notes on the last few days of Wikimania:

  • The cab driver who got me to the airport had (at least) five cellphones. Two were mounted on each side of the steering wheel, and then a fifth appeared from somewhere else half-way through our drive to the airport. Two were Android(-ish?) smartphones, the others older phones. I’m sure there is some perfectly good reason for this, but no idea what it could be.
  • I had been under the impression that the island was essentially entirely either built up or too vertical to build on, so I had wondered how they’d managed to squeeze an entire Disneyland in there. Now I know; it is really quite amazing how much green, open space there is.
  • I was glad to hear Sue say that she cried while watching the South African Wikipedia Zero video, because I did too. As did lots of others, apparently. Still such a long way to reach the 13 out of 14 people on Earth who don’t use us every month, and so many different challenges to surmount – first access, then language, then engagement… oof. But obviously a worth challenge.
  • The 7-11s and Starbucks everywhere in HK are a reminder that the lines between national cultures are blurring faster than they ever have. I still got chicken feet as an unrequested pre-dinner appetizer one night, and unidentifiable fungus of some sort another afternoon. And I did get to see the very interesting, traditional Man Mo temple. But the trend is in favor of homogenization. This is in some ways very sad, as distinctive cultures make the world a richer place, but it will also over the long run make it easier for various contributors to understand each other – the classic mixed bag.
  • At the same time, was reminded in a few ways that barriers to communication are often surprisingly high- for example, a Chinese Wikipedian asked me (quite earnestly) about whether people disagreed about edits on English Wikipedia, which suggested we’re not very good at communicating to new Wikipedians in other languages even the most basic facts. (Asking “do English Wikipedians argue” feels to me like asking “is the sky blue for English Wikipedians?” – almost inconceivable that we haven’t already communicated that.)
  • Chinese Wikipedians are also working on an “intro to Wikipedia editing” tutorial that looks pretty cool. Made me sort of wonder if translating the newly-released How WP Works wikibook (or perhaps a shortened version of same?) might be a good/useful project for young Wiki movements, or if it is better to learn the same lessons through trial and error?
  • The German chapter has three policy people; the Foundation has zero (though all WMF’s lawyers pitch in on policy issues from time to time). I had sort of known this before, but not really internalized it. Still thinking through what that implies. (I had many great conversations with a bunch of the German chapter, and look forward to working with many of them.)
  • Very curious about the economics of the Octopus card. My impression as an outsider is that, through the Octopus cards, Hong Kong has established a defacto digital standard currency without relying on the inefficient, uninnovative, tax-on-the-body-politic leeches known as Visa and Mastercard. But that sounds too good to be true; there must be a catch to it.
  • Several Germans raved about the efficiency, politeness, etc. of the Hong Kong medical system. I chalk this up as a point for the Matt Yglesias “how government services are delivered and executed matters a lot and the US government should pay a lot more attention to that” school of thought.
  • The London organizers are extremely Bold; I wish them great luck in their planning and endeavors. I don’t think it’ll hurt the core conference to try these new experiments, and the payoff if it works could be huge, but I can understand the trepidation on the part of many long-time Wikimaniacs.
  • Had the opportunity to talk to a great variety of people who are passionate about the project; most who were excited and optimistic, some really concerned for a variety of reasons. I hope, of course, with my lawyer hat on, that I was able to calm those fears; in the mean time, it was a good reminder of the depth of passion for the project. (This was one of the many ways where I felt right at home, coming from years of GUADECs- the passion is real and deep and unfakeable in both places.)
  • That said, my biggest personal goal for the conference was to meet a broad cross-section of the community, rather than just the usual suspects from chapters, the board, etc. I feel like I had mixed achievement in this respect- I did have some pretty good conversations with non-chapter, non- (especially with people I met in line for food!) but at the end it was hard to do quite as much of it as I would have liked, especially for non-hacker folks. (The hacking days before the conference made meeting hackers much easier for me than it was to meet non-hacker editors.)
  • This really drove home that in the future, when I go somewhere for a non-Wiki conference, I really need to drop the local village pump or other comms channel an email and see if there is a meetup, editathon, etc. that I can crash.
  • We are deeply adaptable creatures, of course; I was quite overwhelmed by Hong Kong on day one and reasonably comfortable running around it on the free half-day I had before I flew home, and wish I’d had more time tosee it.  Still, it seems to me a city that would be very difficult for me to live happily in without gigantic piles of money.
  • Surprising to me to realize (once it was pointed out by Mako) that many WP articles about a place don’t have a clear link to the equivalent WV page. That seems like low-hanging fruit; I found a couple Monday while seeing the town before my flight and will try to remember to fix them once I’m back on a real network connection.
  • Pretty happy with the two LCA team talks I was part of – we received a bunch of compliments on them, and many great questions from the audience. That said, I think we probably went too broad on the open licensing talk. It either needs to be narrower (only one license or class of licenses) or longer (time-wise) next year, if we make this subject an annual thing. But that is a quibble – overall, I’m pretty happy with the quality of my first impression.
  • I admit that I played buzzword bingo during the Board’s Q&A. I actually think it helped me pay attention to certain topics I might have zoned out a little bit on otherwise, which is good, but the fact that it seems to be played fairly widely may suggest something about the format. I’m not sure what I’d change, though – doing that sort of interaction really does seem like an important way to build trust in the board. (You can mark “social capital” off your Luis Blog Post Bingo card if you’ve read this far.)
  • The closing beach party was a lot of fun, but (with no slight intended to the HK organizers) the top for me will always be the various beach parties at GUADEC Vilanova. For those of you who weren’t there in Vilanova, imagine something like the WM party, but with the broadest beach I’ve ever seen in my whole life, the bar literally in the middle of the sand, and the bar open until 4am. Now that the bar has been raised, I look forward to London’s beach party! ;)
  • Real joy to meet Risker; reminder that these sorts of meetings really allow you to get context and build up a mental model of someone in a way that you just can’t do offline, which makes these soooo important.
  • Copyright reform was a constant and recurring theme of discussion. In six years, certain aspects of Mickey Mouse will start creeping into the public domain, and that means we’re going to have another copyright bill in that time period. I suspect that the as a movement have to be ready and prepared for that, shape and form To Be Determined.

Bottom line: I’m exhausted, and (as I hit my six-months-iversary) more glad than ever I took this plunge. :) See everyone in London!

Wikimania, Day 3

Luis Villa1 Comment
Image

Soooo much. As with the first two days, these are fragmentary notes as much for my benefit as for anyone else’s, so take with bullet points of salt:

Ceremonia_de_inauguración_de_Wikimania_2013,_Hong_Kong,_2013-08-09,_DD_20
Ceremonia de inauguración, by Diego Delso, used under CC BY-SA-3.0, via Wikimedia Commons

  • The lion dance in the opening ceremony was exactly as advertised – a good way to wake up.
  • It was nice to hear the French issue called out in Jimmy’s talk, even if he didn’t call out LCA’s role in it :)
  • The session on the internet in China was informative, but frustratingly brief- needs a lot more detail. Key takeaway: the mainland Chinese Wikipedians appear to believe that turning off http access would be a bad idea. This is a frustrating tension, between access and surveillance.
  • The talk on how Swedish parliamentarians see Wikimedia was not perfect science (response rates were low-ish and skewed in a variety of ways) but the data was still fun and informative. Key takeaways: MPs in .se have pretty positive feelings about WP, and high usage, but assume their co-workers do not have a high opinion of it themselves. I would love to see data similar to this for American politicians, and perhaps as importantly for political staffs.
  • The friendly virtual space policy discussion was interesting, but I am having to recalibrate my timescales and expectations of progress, just because of the vastness and multi-faceted-ness of this community. (At the same time I hope not to become accepting of inaction.)
  • Mako and Aaron’s Wiki Ecology talk was hard to summarize, but very interesting. So much research to be done to understand how FOSS and wiki ticks; I’m glad Mako is doing it.
  • Not all talks are home runs, unfortunately; I like Foucault as much as the next guy (and am quite sympathetic to the notion that pervasive recording influences behavior) but if it comes up in your talk focus may be an issue :)
  • The government copyright talk was interesting, and mostly informative. Good reminder that we should think about if/how to support the state-level government code freeing being done by Carl Malamud.
  • Hallway conversations are great; not surprising.
  • (More?) importantly, for the first time tonight had the great, long, passionate, late night conversations that make you want to say “can’t wait to have a beer with you again next year”. Had a long enough night that I had that kind of conversation with quite a series of people, actually.