Cogito, Ergo Sumana

Categories: sumana | Open Source and Free Culture:Advice:Maintainership book

Book project on open source maintainer skills, starting in 2020


(0) : Sidestepping the PR Bottleneck: Four Non-Dev Ways To Support Your Upstreams: Logo for Upstream: A Tidelift Expedition This is the textual version of my June 7 2021 online talk at Upstream Live: "Sidestepping the PR Bottleneck: Four Non-Dev Ways To Support Your Upstreams", 23 minutes. Video is now up.

Intro

Hi, I’m Sumana Harihareswara. I founded Changeset Consulting, which provides targeted, short-term project management services to open source projects and the organizations that depend on them.

Just so you know, I won’t be sharing any slides today, so feel free to look away from the screen. Do some situps, look out the window, fold some laundry, or something. And: If you prefer to read rather than listen, the written version of this is now up on my blog.

If you want open source projects you depend on to succeed/thrive, then you want to support them.

This is both philosophical (you want to be a good open source citizen) and pragmatic (and ensure the health of projects you depend on).

It’s useful and important to do that through patches. One of the first times I spoke at an open source conference was at Open Source Bridge 2010: “The Second Step: HOWTO encourage open source work at for-profits”. I spoke on freeing up people in a company to contribute changes back and gave steps to widen your internal bottlenecks.

But now, even if your developers have time to polish up changes and submit them upstream, when you submit a patch, the bottleneck is on the maintainer’s side, because they don’t have a lot of time to do code review. You’ve contributed pull requests but they’re languishing. If a project is stuck, the gift you have given them isn’t helping – it’s like you’ve given them a gift card to a store that’s really hard to get to, so you’re not really helping them substantively.

Lack of time to do code review is common, so it’s likely your PRs aren’t helping as much as you’d thought!

And that’s if your developers even have time to make and polish PRs; maybe your developer resources are slammed, but you have other folks on your staff whose time is more flexible.

So let’s go into how you can develop a deeper toolbox, and how you can help projects you depend on, including expanding their code review bottleneck. Which benefits you and them.

So today I’ll share case studies and discuss 4 ways to help:

Testing infrastructure

First off, let’s talk about how your operations department can help developer throughput for a project you depend on – by providing access to infrastructure for use in testing.

As an open source project matures, it comes to a crossroads where maintainers have to ask: what platfoms are we going to support, and how robust will our support be? And their access to testing infrastructure, especially for continuous integration, becomes a key turning point that determines how robust it will be.

Let’s say they want to support the three basic OSes: Windows, Mac, and Linux. But wait, which VERSIONS of those platforms will we support, and which Linux distributions? So now we already have probably at least six or seven things to test.

But what else are we going to support? AMD and Intel chips? People who do and don’t have a particular soft dependency installed? People who run Python 3.5, 3.6, and 3.7?

You can see how these options multiply out, until the project has a test/support matrix with 56 environments.

And, often, projects are limited enough that they can’t rigorously and consistently test their whole matrix – a lot of open source projects can’t afford paid continuous integration services, and they don’t have enough virtual or physical computers to test all the environments they want to support. So maybe 56 environments is too much to handle, and the project ends up with two tiers of support – rigorously tested environments, reflecting the developers’ personal machines, and then everything else. If none of the developers use Windows then Windows is in that “might work” category.

Or the CI services they use limit how many simultaneous jobs they can run, and that slows down the revision and review cycle. Instead of taking 30 seconds or a minute to run CI it might take 10 minutes, or even an hour during peak contribution times like hackathons. This also creates pressure to reduce the number of tests that run on every patch, which means that maintainers have to take more time to review every patch before merging it.

But you can help with this. As a company, you can help your upstream open source projects by providing infrastructure. Give them access so they can use your testing setup for their continuous integration. This is especially useful if your cloud includes the ability to spin up proprietary OSes.

Broader and faster CI helps developer throughput and, in particular, helps the code review cycle go faster.

Money

Next: money.

You’re here at Upstream, so you know that subscribing to a project via Tidelift gives you better assurances of a project’s security, reliability & legal compliance.

But you might be saying: Sumana, how does money specifically help widen the code review bottleneck?

So let’s talk from the point of view of maintainers & what they can do, using lifter income.

First off, with enough income, if a maintainer is spending their time at a job working on something else, sometimes they can quit, and spend time on their open source project.

I’m gonna take a moment now to talk about why that is SOMETIMES. And it has to do with health care and health insurance.

But that’s SOMETIMES. People in a lot of countries, when they quit a job, or go to part-time, they don’t have to worry about how that’ll affect their health insurance. Or, if you’re a tech worker in the US who doesn’t depend on your employer for health insurance, then you have some flexibility, and the more lifter money you get, the more time you can spend on open source. Like if you’re a student getting health insurance through your school, or it’s coming through your spouse or your parents, or you’re a veteran or a senior citizen and you get health insurance through the government.

A lot of tech workers in the US, though, would need to make A LOT of money from lifter income to quit their jobs, buy health insurance on the open market, AND be confident that they could continue to afford that even if the prices go up. So they have less flexibility, and money might not translate so directly into more hours of work.

OK, so, back from that sidebar.

But even so, even if someone can’t quit their day job, so the maintainer still has the same number of hours to spend on their open source project, money can still translate into BETTER work.

A huge example of this is EQUIPMENT. A lot of people volunteering in open source have old or inadequate computers at home, or they don’t have a proper desk, chair, secondary monitor, and stuff like that. A more efficient home office setup – or even JUST a second monitor – can help the quality and speed of someone’s work. Some one-off donations can pay for that, and then over time, a steady lifter income (of a few hundred bucks a month) can help someone move to a bigger place, pay more in rent or mortgage, so they can have a proper home office, with a door that closes, and faster Internet.

Another example is EDUCATION. A lot of open source developers, when they want to learn a new skill, default to looking for what they can read for free online. But someone who’s getting some steady lifter income can pay for books or one-off tutorials to level up, or subscribe to a paid content platform. Like, O’Reilly’s learning platform is $50/month.

And part of how we educate ourselves and each other is with conferences. But most conferences cost money to attend. Sometimes prices for conferences assume all the attendees have their registration costs covered by an employer or a university, and registration costs hundreds of dollars, even over a thousand dollars. Not to mention, if it’s an in-person conference, travel and lodging costs. Lifter income can make the difference, and make going to a conference affordable.

And another example is PAYING INTERNS and FREELANCERS. For example, a maintainer can save up lifting income to pay a freelance writer or designer to improve their website or their documentation, which will save them user support time. Or, for example, a large one-time donation can help break a review and release bottleneck. Last year, donations made it possible for my company to hire a GNU Autoconf expert to get a release out the door, 8 years after the last release. Zack Weinberg took more than six months to review and merge 157 patches, most of which were bugfixes, and make several beta releases, and finally release Autoconf 2.70.

Or a maintainer can save up income to pay an intern, and to teach them to become a co-maintainer. For example, the Outreachy internship program costs a mentoring organization $6500 per intern.

And speaking of interns:

Secondary mentorship

Let’s talk about interns and secondary mentorship. Here’s another way a company can help- you can help a project develop new contributors, and help them get further along the road to becoming co-maintainers.

Think about the engagement funnel for an open source project that wants more contributors and more co-maintainers. An individual contributor starts off not knowing project exists, then becomes interested, and starts contributing. Then, if the project can retain and grow them, they may grow skilled and trustworthy enough to be promoted to become co-maintainer of the project. And the more maintainers you have, the more time is available to do code review.

You can help with a few parts of that funnel. For one thing, if the project isn’t getting new people at the start of the funnel, your marketing department could help with that, with attracting new contributors in the first place. But a lot of the projects you’re working with are actually bottlenecked further along than that – maintainers don’t have enough time to mentor the contributors they have, and grow them to the level where they can promote them.

So I recommend that you help provide SECONDARY mentorship.

When an opensource project is trying to grow new contributors, they often work with internship programs, such as Google Summer of Code or Outreachy. Someone from the project mentors an intern, who’s often new to open source, for three months. But that mentor is usually doing this on top of their other responsibilities. And they’re often pretty new to management, and they’re almost always managing remotely (which is harder than in-person when you’re training someone new), AND sometimes that intern has never had a professional job before and has to learn basic professional skills along the way.

So, that mentor, one of the project maintainers, has a lot of domain knowledge about the project’s codebase, but could probably use an extra pair of hands. This is where you can come in. You can be a secondary mentor.

A secondary mentor does not need to be an expert in or even a contributor to the project codebase. Here’s an example: when I was working on MediaWiki a few years ago, I worked with an Outreachy intern named Frances Hocutt – this was his first programming job, as he was switching careers out of chemistry. Frances’s project was to evaluate and improve the web API client libraries for MediaWiki, in Java, Perl, Python, and Ruby.

One of his mentors was me, but I gathered a co-mentor and two technical advisors: engineers who have different strengths, live in different time zones, and who all promised to respond to questions within two business days. Frances was reading and writing code in four different languages, and was able to get guidance in all of them. The other guys had very different perspectives. Tollef has worked in several open source contexts but had never worked on MediaWiki, so he could approach MediaWiki’s API with learner’s mind and help Frances by modeling how he reasoned about it. Brad had hacked on the API itself and maintained a popular Wikipedia bot that uses it. And Merlijn is a maintainer of an existing client library that lots of Wikimedians use. I brought deep knowledge of our technical community, our social norms, and project management. And I was in charge of the daily “are you blocked?” communication so we could avoid deadlocks.

This worked really well. It made it possible for people to take vacations without Frances getting stuck, and to have more guidance available – from day to day, to help him stay unblocked and always have a next action he could take, but also on bigger topics, like about programming careers and engineering standards, how to judge whether his work was good enough. And after his internship, Frances actually got hired by the Wikimedia Foundation.

Outreachy now highly recommends that every intern has at least two mentors -- and in fact, when I run these mentorship programs, I often MANDATE that every intern has 2 mentors.

See if you can complement a primary mentor by being in a different time zone, and bringing different SKILLS – like project management, technical communication, or testing. You do not have to be a developer to do this. As long as you are reasonably literate in open source process in general, and you actually like helping people learn, you can really improve the odds that an intern will succeed at their internship, want to stick around, and get closer to becoming a project co-maintainer.

Coaching and cheerleading

Finally, let’s talk about coaching and cheerleading – I’ll talk about a time when being an encouraging sidekick made a huge difference.

I did some volunteer work last year, helping rejuvenate pipenv (a command-line tool that some people use to help handle Python packages they make and use).

Pipenv’s maintainers had not released a new version since November 2018, and users were concerned (in many cases switching to competitors). In early March 2020, someone suggested that perhaps the official Python Packaging User Guide should stop recommending it. I saw that suggestion and went into the relevant Internet Relay Chat channel to nudge one of pipenv’s maintainers and to ask: what do you need? What’s blocking you?

Dan knew what was blocking him. He said: “if you’re purely evaluating ‘how do we release the code’, yeah I might just be the main roadblock?” and said he needed “someone to yell at me to stop doing things that are not related to the goal?”

I said: “if you JUST want someone to yell at you to stop doing those unrelated things …. would you actually listen to that person?”

he said: “historically speaking, I’d insist I was doing something important briefly but probably reassess, I do know what needs to happen”

So, over the next three months, I donated about 15 hours of my time. Given my current hourly rates, this constitutes a donation worth a few thousand dollars, which is infinitesimal compared to the value unlocked by expediting a pipenv release. And with those 15 hours of work, I enabled Dan to do fix bugs, do code review, merging several pull requests in, and to make the release – releases mean your patches get not only reviewed but also released so you don’t have to maintain a fork! All in all, with my help, Dan released two betas, then a stable version in May.

Dan needed someone to help him with prioritization, release management, and communications. So I:

That was 15 hours in total.

Those 15 hours of coaching and communication and cheerleading enabled Dan to review pull requests, fix bugs, and get that release out. And since then pipenv has made releases on a pretty steady clip.

So: An external perspective can help a lot. You can be that person. Whether you call yourself a sidekick, a project manager, a cheerleader, a coach, or something else, you can be a supportive accountability partner who helps with the bits that maintainers are not great at, or don’t have time for. And you don’t have to know the project codebase to do this, or be a feature-level developer - the only pipenv code I touched was the docs.

If you/your company depends on an open source project and you’re getting annoyed or worried because the release cadence has slowed to a standstill, there’s a strong chance you can turn that around. If someone on your team can spend a few hours complementing the existing maintainers and helping unblock them, that could save you a bundle compared to forking or switching dependencies. Try talking with the maintainers about what they need. And I do mean talking, as in, synchronous conversation via voice or chat, so you can build some trust and get the kind of conversation I had with Dan.

Conclusion

So: testing infrastructure, money, secondary mentorship, and coaching and cheerleading can all move the needle, to increase the health of projects you care about – and decrease the code review backlog so your patches get into the mainline.

I’m Sumana Harihareswara, and I can help you make this happen through my consultancy, Changeset Consulting. And let’s talk more in the chat after this talk – I’d love to hear your stories about what works.

Filed under:


(1) : A Spec For A Sandboxed Open Source Project Environment: I'm writing a book on maintaining legacy open source projects to help teach people vital skills. Right now, as far as I know, there's no textbook or course you can work through to learn skills like assessing an open source project systematically, triaging bugs, noticing quiet-but-promising contributors to promote, improving code review processes, writing a grant proposal, and finding your successors. Or, more accurately, there are courses and guides that cover different software leadership areas, but there's nothing that covers the whole toolbox.

When I'm teaching skills, I want to give learners exercises they can use to develop and practice those skills. And if I turn the book into a course, I'll want to be able to assign those exercises and review their homework. So I started thinking: how nice it would be if I could snapshot or composite together a sample legacy FLOSS project, complete with messy old issues, docs, and chat and list archives, and replicate it in self-serve sandbox instances for exercises!

I've been thinking about this for a while. Today I wrote up a spec. I don't know what to call it - "Maintainer Sandbox", "Snowglobe Factory", and "Diorama" all sound good. The spec below assumes that I'd be leading a cohort of learners through a semisynchronous online course; it would work fine for an in-person class as well, but I'd have to adapt the access levels part for a completely self-paced and self-driven course.

Spec

As instructor, I would create a snapshot of a sample open source project (comprising materials listed below). The hosting platform would replicate it in self-serve instances, usable over the web, for user exercises. Upon signing up for a course, a user would get access to a freshly provisioned instance, complete with project history.

Materials: Each instance would include the following artifacts, all browseable and searchable via the web browser:

(Olivier Lafleur conversed with me on Twitter about how to do some portion of this using GitLab. Also, the Perceval project may be a good tool to consider for mailing list and chat archives.)

Access privileges: The learner would not only interact with the example project materials as a reader but also as a participant, moving through the three access levels described below. The instructor would be able to view a learner's instance, with administrator (Level 3) access, to assess the learner's actions.

Authentication: I imagine that dealing with authentication within the application could get sticky. My preferred approach:

Multi-user access: Ideally, it would also be possible for an instructor to expand access so that a project can have multiple users (in other words, give Learner A access to Learner B's project instance), so that learners can engage in peer learning and group exercises. However, I expect that would lead to a much larger range of headaches, including Code of Conduct problems in interactions between learners, so -- in earlier versions of this tool -- I am fine with not having this functionality, and instead advising pairs and small groups to use screen sharing for group exercises.

End of life: At the end of the course, each instance would turn read-only for two weeks (to allow the learner to make notes, and to make local copies of any work they had done), and then the platform would delete the instance.

Thoughts? In particular, if you know of software that already does more than half of what I want, I'd like to know about it.

Filed under:


: MozFest 2021 Followup: Apply for Grants To Fund Open Source Work:

This session was in two parts:

  1. a fifteen-minute video (a remix of the session I delivered at PyOhio, with five additional minutes of material)
  2. a one-hour discussion

The additional material in the MozFest video (slides, rough script) included:

The discussion was lively and varied. We talked about several topics and shared resources, and wished there were a thorough aggregator of funding opportunities for open source work, bigger than the one that the PSF's Project Funding Working Group has put together.

Some funding opportunities people brought up:

And we discussed the question "how do you get a community going and solicit money when you don't have anything to show yet?" and the fear that people will steal one's ideas, and the problem of answering funders who ask you "how will you sustain this project after the funding ends?"

Some other resources people mentioned:

Thanks to everyone who watched or participated!

Filed under:


: MozFest 2021 Followup: How To Get A Project Unstuck:

This one-hour discussion session covered some of the same material as my Linux.Conf.Au 2021 lecture, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here" (outline and links; video).

Below are some session notes, including some of the live collaborative document we used to take notes during the discussion. I've removed individuals' and projects' names.

Case studies

Autoconf (Case study: rejuvenating Autoconf; also see how my upcoming book is helping Autoconf's developers decide what to do next)

Pipenv (Pipenv case study)

Asking participants about their projects

Principles of getting a project unstuck

Some premises I use in my work:

Five major areas where legacy projects get stuck. I need help with the names for these categories! (And of course sometimes combinations of problems crop up.)

  1. strategy, e.g., what work do we need to prioritize, and how urgent is it? what is our goal, and should this project exist (or should we decommission it)? has the team agreed on these things?
  2. team, e.g., do we have enough maintainers to do the essential work, and do we have up-and-coming contributors who can replace us as maintainers in the future? does everyone know who has what powers, or are some people confused about who has the power to do certain things? do we run into team workflow problems when different groups want to participate at different speeds? is there a malicious, offputting, or flaky person who needs handling? do we have the social processes we need to support the project and each other, like meetings, mentorship programs, and Requests for Comment?
  3. connection, e.g., who are our users and what do they need? are we listening to them? are we responding quickly enough to their concerns? do they have a way of listening to us? who are our partners and upstreams? do we talk to each other? do new contributors fall through the cracks?
  4. workflow and digital infrastructure, e.g., do we run automated tests on every patch? do new issues, patches, and discussions get interlinked so developers and users can easily follow up? are there bottlenecks or duplications in the platforms we use to respond to issues, review code, and discuss the project in general?
  5. money, e.g., do we have enough money to do what we want to do? have we developed plans or proposals to turn money into progress? can we persuade funders to give us money?

Thank you to a participant who suggested "interfacing" rather than "connection". I do like that better.

The sequence of steps for gaining credibility within a project and helping turn it around:

  1. Settling in (doing routine tasks that do not require much trust, assessing and earning credibility)
  2. Taking charge (doing things that require trust but that the group has already agreed needs to happen)
  3. Making change (modifying and adding social, digital, financial, and legal infrastructure)
  4. Passing leadership over to successors and leaving

This is the outline of my forthcoming book. My sampler ebook of Getting Unstuck: Advice For Open Source Projects, available for free download once you subscribe to my 1-10 times per year newsletter, includes that full outline.

Questions & discussion

What kinds of "stuckness" have you seen in FLOSS projects? I feel like I've seen 5 major areas where legacy projects get stuck (strategy, team, connection/interfacing, workflow, and money). Does that reflect your experience?

What circumstances make it easier or harder for projects to get unstuck?

(I was struck by how much easier it was for participants to come up with programmer-specific problems -- especially problems with onboarding new contributors -- than to remember and bring up people, money, and other problems. After all, most mature software projects have a backlog of patches awaiting review, and so making it easier for more new contributors to get onboarded is a less crucial bottleneck than widening the code review bottleneck, which is probably a team, workflow, and money problem.)

Do you know a stuck project? What support would you need to start getting it unstuck?

Plans for followup

I suggested that people form optional accountability pairs, to talk with each other regularly and help both stay motivated to get their project unstuck. Two people did pair up.

Filed under:


: Gaps in Existing Guidance on Open Source & Software Management: Getting Unstuck sampler cover I'm working on a book proposal for the full-length book version of Getting Unstuck: Advice for Open Source Projects (38-page sampler available now for free download when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).)

In the process, I've developed a list of existing books and online resources on open source maintainership and on software management, and I've thought more about why general software management advice -- which usually assumes you and your colleagues all work for the same company or other organization -- doesn't address most open source maintainers' needs.

Writing a book proposal: kind of necessary, kind of a drag

In nonfiction book publishing, a book proposal is the way you say to a publisher, "I think it would be a good deal for both of us if you published this book I'm writing." For example, No Starch Press would like a summary, an outline, and descriptions of the audience, the competition, the market, and the author. All the publishers I'm considering want to know those things, and some also want to know the schedule for completion, which other books from that publisher cover related or similar topics, the authorial approach I'll use, what keywords readers would search for to find this book, and more.

I might not go with a traditional publisher; I might self-publish, either all at once or in stages, such as via my email newsletter. But writing this proposal gives me more options and makes me think through what I'm planning to do. Still, it can be a drag to spend time on persuading other people that something is a good idea instead of executing on the idea itself, and it is a specific drag for me to spend time writing something that very few people will see.

The most immediately-useful-to-others part is probably the literature review, the overview of books and similar resources that are in any way comparable. Thus:

My competition

So here's my competition. I don't mean to disrespect any of these works or their authors, just to clearly state what they do and what they don't do (and thus why there is still a need for my book).

I hired Audrey Eschright to start this and then I continued it myself -- thanks, Audrey! I know this is incomplete and I'll remember another thing three hours after I post this (I may edit to add things), but I figure it might be useful to folks looking for books and web curricula about open source, project management, maintaining legacy systems, and so on.

Open source & related

Software management

(There are dozens of reasonably well-regarded books on software management in general, from classics like DeMarco & Lister's Peopleware to more recent works like the Fournier I mention below; most of them are only partially suitable for my target audience for the reasons I mention in "What doesn't get covered".)

If I've made any substantial errors in my descriptions of these books and websites, please let me know. And if you think I've missed a work, if you think the book I'm working on substantially overlaps with prior work that I have not mentioned, please tell me. I don't want to waste anyone's time and I wish to minimize duplication of effort.

What doesn't get covered

There are lots of guides to starting open source projects, but overall they do not address the needs of a new maintainer of a legacy project. As Marco Rogers recently observed regarding code-related tutorials: "there is very little content that is appropriately labeled as intermediate to advanced....A lot of content is pointed towards either newbies or people doing greenfield work."

And there are many books about managing software projects, including complex infrastructural and legacy projects. They generally assume you're making proprietary software, and so (except for works like Bacon's) they don't account for the benefits of working in the open, the possibility of getting gratis contributions from users, open source strategy for the enterprise, and so on.

But also -- more crucially for a project management book -- on the whole they assume that all contributors are paid staffers, usually of the same organization. This is a somewhat less obvious distinction so I'll discuss it at a bit more length.

The job of a project manager varies wildly depending on how much power you actually have to say no to things and change delivery deadlines, whether you have the power to hire and fire people, and whether the colleagues who work on your project are solely working on your project (or splitting their time among multiple projects). Much of the existing writing on software management assumes that you are working in a mostly-hierarchical environment bounded by a single organization, where someone has the power to hire and fire, there is a monetary budget you control or have to keep track of, and so on.

Certainly some orgs are more hierarchical than others and there exist some where you basically have to use persuasion if you want a change to happen. First, of course that dynamic privileges some people, and it's worth checking for -isms in who gets to just veto things for no reason and who doesn't. And second, even so, if you and the other people you are influencing are in the same org and are being paid by the same employer, you still have different cues and levers available to you. Here are some structural differences between managing a more cross-org or extra-institutional project and managing one where everyone is being paid by the same employer:

Thus: my book

So I am continuing to work on the full-length book version of Getting Unstuck: Advice for Open Source Projects (38-page sampler available now for free download when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).)

Once I finish this proposal.

Filed under:


: Outline and Links for "How To Get A Project Unstuck" LCA Talk: Here's a brief outline, and relevant links, for the talk I'm about to give at Linux.Conf.Au: "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". I am not presenting any slides.

Introduction

My consultancy is Changeset Consulting.

Stories

  1. Gathering info and helping decisions:

    WisCon

    Mailman (What was new in GNU Mailman 3.0, announcement of the Mailman 3.0 release)

  2. Gathering funding:

    Video, transcript, and slides for my PyOhio talk on applying for grants to fund open source

    "Problems and Strategies in Financing Voluntary Free Software Projects" by Benjamin Mako Hill

    Autoconf (Case study: rejuvenating Autoconf; also see how my upcoming book is helping Autoconf's developers decide what to do next)

  3. Nudging, prioritizing, and communicating:

    Pipenv (Pipenv case study)

A case study I didn't have time to discuss in this talk: Finishing the rearchitecture and deployment of PyPI.

The credibility and change sequence

This is the outline of my forthcoming book. My sampler ebook of Getting Unstuck: Advice For Open Source Projects, available for free download once you subscribe to my 1-10 times per year newsletter, includes that full outline. The basics:

  1. Settling in (doing routine tasks that do not require much trust)
  2. Taking charge (doing things that require trust but that the group has already agreed needs to happen)
  3. Making change (modifying and adding social, digital, financial, and legal infrastructure)
  4. Passing leadership over to successors and leaving

I may also refer here to "Software in Person", my article on how to make the most of synchronous developer events.

Why maintainers usually don't have these skills

Where maintainers come from, what we value and grow, and a lack of tools and practices to help learn and teach these skills.

Let's change that

Existing initiatives or resources to improve and teach these skills:

Ideas for further tools and practices to improve skills (this is where I mention possible improvements to GitHub's "saved replies" tool).

Conclusion

Thanks for watching and listening. I look forward to hearing your thoughts, so please contact me to let me know!

Edited Feb 5th to add: video is now up! And thanks to Nick Murphy, R. Fureigh, and Keffy R. M. Kehrli for being test audiences!

Filed under:


: Advice From My Book Helps The Autoconf Project Assess Itself: A few weeks ago, I released a sampler from my upcoming book on rejuvenating open source projects: Getting Unstuck: Advice for Open Source Projects. It's like a lengthy trailer in text form.

Getting Unstuck sampler cover, with graphic of a flowing river

You can get this 38-page ebook for free when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).

And readers are already using what they learned in this book to help their open source projects level up. Zack Weinberg, who worked with me to start rejuvenating Autoconf, read the sampler and learned a lightweight framework for assessing a project. He immediately used it to assess the GNU Autotools:

Should development of the Autotools continue? If they are to continue, we need to find people who have the time and the inclination (and perhaps also the funding) to maintain them steadily, rather than in six-month release sprints every eight years. We also need a proper roadmap for where further development should take these projects. As a starting point for the conversation about whether the projects should continue, and what the roadmap should be, I was inspired by Sumana's book in progress on open source project management (sample chapters are available from her website) to write up a "strengths, weaknesses, opportunities, and threats" analysis of Autotools.

This inventory can help us figure out how to build on new opportunities, using the Autotools' substantial strengths, and where to invest to guard against threats and shore up current weaknesses.

Zack sent his writeup to the Autoconf mailing list where it's spurred a productive discussion about project architecture and inter-project coordination -- see his followup message about particular tasks that, if funded, could address concerns that he raised. These concrete proposals will make it easier to seek specific grants or directed donations from funders -- companies, foundations, etc.

The sampler is a free 38-page ebook (PDF, ePub, and MOBI available) that includes:

Get the sampler for free when you subscribe to Changeset's email newsletter (1-10 updates per year).

And, in about a day and a half, I'll speak for the first time at Linux.Conf.Au, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". I'll tell some stories of projects I helped get unstuck, and share more material from the forthcoming book. Ticket sales are now open for LCA (which is, of course, a virtual convention). Buy a ticket if you'd like to see my talk live and participate in questions-and-answers!

Filed under:


: New Free Ebook Sampler from "Getting Unstuck: Advice for Open Source Projects": I've written and released a sampler from my upcoming book on rejuvenating open source projects: Getting Unstuck: Advice for Open Source Projects. It's like a lengthy trailer in text form.

You can get this 38-page ebook for free when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).

Getting Unstuck sampler cover

Who this book is for and what you should get out of it:

You are about to get an open source project unstuck.

Maybe a bunch of work is piling up in the repository and users are getting worried, waiting for a release. Maybe developers have gotten bogged down, trying to finish a big rewrite while maintaining the stable release. Maybe the project's suffering for lack of infrastructure — testing, money, an institutional home.

You noticed the problem. So that means it's up to you to fix it. Or you're getting paid to fix it, even though you didn't start this thing.

A while ago I blurted out the phrase "dammit-driven leadership." Because sometimes you look around, and you realize something needs doing, and you're the only one who really gets why, so you say, "Dammit, okay, I'll do it, then."

After reading this book, you should be prepared to:

  1. Assess a legacy project to decide whether you should get involved.
  2. Settle into a legacy project and become a competent and credible contributor.
  3. Take charge of a legacy project on a project, people, and financial level.
  4. Execute transformative change in a legacy project.
  5. Make a legacy project more sustainable, and pass leadership on to someone else.

This sampler is a free 38-page ebook (PDF, ePub, and MOBI available) that includes:

Thanks to Julia Rios for paid services editing and producing this book, including the cover! Julia is a Hugo Award-winning editor as well as a writer, narrator, and podcaster, and is available for freelance work!

A special note for my blog readers: I'm keenly interested in your feedback once you read the sampler. Have you solved any of these problems in a different way? Would a different structure, for each chapter or for the book, help you better? Did any of my examples or phrasings particularly ring true? Are there things I've written that you have found useful and that you hope I will incorporate into this book? Email me with "Unstuck" in the subject line.

Next: In 2021 I'm looking forward to finishing this book and either self-publishing or working with a publisher. And I will likely bring this sampler from behind the subscribewall once I produce a new edition of it that can have a "the full book is coming on [date] from [publisher]!" line. In order to do that, I need to finish the book proposal, submit it to publishers, and get cracking on the rest of the book.

Get the sampler for free when you subscribe to Changeset's email newsletter (1-10 updates per year).

Filed under:


: Two Upcoming Sumana-Talks-At-You Events: Most urgently: You have just over 24 hours to back the Mermaids Monthly project on Kickstarter, supporting a fun, independent speculative fiction magazine for 2021. If you back at the $100 “Subscription, Pin, and Poetry” pledge level, you'll get invited to a special Zoom party where I'll perform stand-up comedy.

And: in late January, I'll speak for the first time at Linux.Conf.Au, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". You'll come away from this talk with steps you can take, in the short term and in the long run, to address this for projects you care about. Ticket sales are now open for LCA (which will of course be a virtual convention). Buy a ticket if you'd like to see my talk live and participate in questions-and-answers!

This talk will draw from the same material as the book I'm writing on getting open source projects unstuck. I aim to teach the skills open source software maintainers need, aimed at working scientists and other contributors who have never managed public-facing projects before. And I hope to have more news about that project soon!

Filed under:


: Nonfiction Book Writing in November, and Daily Wordcount Posting: I am writing a book about open source maintainership. I had planned to get the book to editors/agents by the end of this year; I have made very little progress on it this year so now my goal is to have a small self-published early version of the book available by the end of the year.

Recently I wrote up a blog post about how the hobby writing project I did Sept-Oct felt doable for me, and how to apply those lessons to my book project I've been procrastinating on. Having a little writing prompt every day feels like it will help. I'm also planning on blogging stuff as I write it, or posting it publicly somewhere. Maybe a GitLab repo to start?

November -- there's NaNoWriMo. It's for novels. I saw that there are some rebels who use it for nonfiction, but I don't want to deliberately contravene the goals of NaNoWriMo so I'm not signing up for it formally, but I am committing to writing each day in November as a way to accumulate a lot of progress and momentum for the book.

Today I sat down with Leonard and he helped me restore my faith in my current outline, and I developed a template for each chapter which will make it easier for me to write them, and I wrote seven writing prompts so now I have writing exercises/chapters to start for each day in the coming week.

I also signed up for a daily words community on Dreamwidth to give myself people I am accountable to. I will also tell y'all: I want to write 400 words per day in November, as a minimal goal. On good days I know I will blow way past that! But just -- every day I want to write at least 400 words.

Any of you doing daily writing in November? If you're posting daily "I wrote [number] words!" then where are you doing that? I'd like to join in.

Filed under:


: Short Story Recommendations, And Hobby Project Lessons: Recommending short fiction is important for discovery, and to help us talk about things we like (and not just criticize things we don't).

Recently I've been posting to MetaFilter each day to recommend short stories, mostly scifi/fantasy but not always. For example, I pointed to Brishti Guha's translation of a (wacky, in my opinion) 11th-century Sanskrit piece by Kshemendra about language misunderstandings and an angry scholar. "...the reason the meat was so poor was because hunters couldn’t get hold of any well-fed animals. All the animals wanted to listen to Gunadhya’s story even more than they wanted to eat!" I enjoyed this fragment so much that I called my mom and read it aloud to her, and she told me cool stuff about the Sanskrit in-jokes in the story.

Other MetaFilter participants said nice things about how much they like the series which is nice to hear. Lots of people have said, in comments in that thread or on individual posts or in private mail to me, that they value getting these recommendations, that they are eager for links to good short fiction to help them read great stuff instead of getting sucked into the whirlpool of reading distressing news. Similarly, I have found it nice to have a wee research project, and to have a little template for bite-size things to write and publish that people enjoy. And I've discovered some cool magazines I hadn't known about before, such as Compelling Science Fiction and Cossmass Infinities.

I started posting these in late August. I decided that I'll stop at the end of this month, and suggested sources for folks who want to keep going.

And I've learned some things about what I found motivating about this project, and am working on adapting those lessons to my book project so I can get more traction.

Overall, I seem to benefit from having consistent frequent but delayed publication/gratification (which suggests a drip marketing approach as Julia Evans has just blogged about), having a clear vision for what each little chunk of work is supposed to be like (which suggests I need to bear down on outlining work), and external validation from eager readers (which suggests I should set up a few oral conversations sometime soon with people who need a book about brownfield maintainership).

Filed under:


: Breaking Release Bottlenecks -- What Changeset Can Do: I did some volunteer work earlier this year, helping rejuvenate pipenv (a command-line tool that some people use to help handle Python packages they make and use). Here's what I did, how long it took, and how you can do the same.

Pipenv's maintainers had not released a new version since November 2018, and users were concerned (in many cases switching to competitors). In early March of this year, someone suggested that perhaps the official Python Packaging User Guide should stop recommending it. I saw that suggestion and went into the relevant Internet Relay Chat (IRC) channel to nudge one of pipenv's maintainers and to ask: what do you need? What's blocking you?

Dan Ryan ("techalchemy") knew what was blocking him:

techalchemy: if you're purely evaluating 'how do we release the code', yeah I might just be the main roadblock?
techalchemy: someone to yell at me to stop doing things that are not related to the goal?
techalchemy: lol
sumanah: let us assume that a successful release -- even as a pre-alpha -- is something that does not instantly break every user's life
techalchemy: yeah longer term planning though would require tech writing for sure and onboarding help, god do I struggle with that
techalchemy: have you heard me explain something...
sumanah: if you JUST want someone to yell at you to stop doing those unrelated things, just for about a month, then that can be cheaper .... would you actually _listen_ to that person?
techalchemy: historically speaking, I'd insist I was doing something important briefly but probably reassess, I do know what needs to happen
sumanah: :-) ok. So, how frequently do you need those checkins? like, 4 times a day, 5 days a week?
techalchemy: hopefully not that much, but I could see a few checkins being helpful especially if we were also onboarding some new people
sumanah: techalchemy: ~10 minutes of conversation, via IRC, 4 times a day, 5 days a week, for 3 weeks....

That would have worked out to about ten hours. We underestimated how long it would take Dan to address some nasty continuous integration bugs, so instead of three weeks it took three months. Over those months, I donated about 15 hours of my time, helping him release two betas, then a stable version in May. Given my current hourly rates, this constitutes a donation worth a few thousand dollars, which is infinitesimal compared to the value unlocked by expediting a pipenv release.

Dan needed someone to help him with prioritization, release management, and communications. So I:

Phil Gyford noticed that initial IRC conversation and said:

It's kind of fascinating as an example of bottlenecks in open source development and the importance of project managers.

And Yoz Grahame replied:

I regularly have conversations like this, and it's a toss-up as to which of the two roles I play.

Yeah. An external perspective can help a lot. And, ideally, a project manager is a supportive accountability partner who helps with the bits you're not great at.

If you/your company depends on an open source project and you're getting annoyed or worried because the release cadence has slowed to a standstill, there's a strong chance you can turn that around. If someone on your team can spend a few hours complementing the existing maintainers and helping unblock them, that could save you a bundle compared to forking or switching dependencies. Try talking with the maintainers about what they need. And I do mean talking, as in, synchronous conversation via voice or chat, so you can build some trust and get the kind of conversation you see in the IRC log above.

Or: contact Changeset Consulting for a free initial 30-minute chat. Maybe it'll only cost you a few thousand dollars to get that bottleneck unblocked. Let's find out!

Filed under:


: Remedial Skills In Open-To-The-Public Working Groups:

I'm talking in this post about wikis, political clubs, open source projects, fanvidding exchanges -- any groups where people try to work together and are open to the public.

"No, what's that?"

Some people joining your groups don't know things you take for granted.

Years ago, while helping new applicants to Google Summer of Code get into working on (I think) MediaWiki or Zulip, I was talking with a person who was (at that time) a student in an Indian engineering college. He had run into trouble and was trying to debug a setup issue. He seemed to be asking for help but not systematically investigating what the problem might be.

So I said, let me give you some tips on troubleshooting. You've heard of the scientific method?

He said: no, what's that?

I gave him a link to the Simple English Wikipedia article on it -- and to the They Might Be Giants video for their song "Put It To The Test", on forming falsifiable hypotheses and testing them. I asked him to watch and read them and then tell me when he had done so. He did.

They Might Be Giants - Put It to the Test from They Might Be Giants on Vimeo.

I then said: so, you do that. You come up with a hypothesis for what might be the problem, and figure out how you would check to see if that is the case. You run the experiment, and you use the resulting data to refine your hypothesis -- if you're wrong, you try to come up with a new hypothesis. And then you either find and fix the problem, or if you get stuck, you at least have a bunch of data to give someone so they can help you better.

He said: THIS IS AMAZING! I'M GONNA USE THIS ALL THE TIME! And I was like IT IS! And then in a separate private conversation with colleagues, I was privately very angry with the educational system that had let him get that far without teaching him this!

[This is one of the experiences that led to me writing a fairly well-regarded blog post for new open source software contributors, on the scientific method, learning from and contributing to shared notes and logs, and self-reliance and interdependence.]

Lessons

Some lessons here for you:

  1. Don't act surprised when people say they don't know something. Because (as I said a few years back) that’s just a dominance display. That's grandstanding. That makes the other person feel a little bit bad and makes them less likely to show you vulnerability in the future. It makes them more likely to go off and surround themselves in a protective shell of seeming knowledge before ever contacting you again.
  2. Some gaps you can remediate. Sometimes it's as quick as the explanation and links I used above. Sometimes it's more involved, as with providing free English tutoring to your internship applicants. Sometimes remediation takes a lot more work, and you may not have time to provide it; see my suggestions in "How to Teach And Include Volunteers who Write Poor Patches" which include some lower-effort options, like the section "Using their knowledge and curiosity to improve the project in other ways."

    In open source projects, I think it's also okay to exclude unskilled people from a project based on "we do not have time to help them learn remedial skills, and this is not a suitable project for novices." If you are going to do this, explicit is better than implicit. You should try to forewarn contributors with explicit "not good for beginners/prerequisite skills are [list]" language in your README and CONTRIBUTORS files. And when you need to tell contributors that they aren't ready to participate in your group yet, you should offer them a redirect to a project more suitable to their skill level, you should take care not to insult them while redirecting, and you should tell them they'll be welcome back in the future after learning more of the prerequisites.

  3. The scientific method is still as kickass a cognitive tool as it has ever been. It's amazing and empowering!

Thanks to Dr Linda McIver for the conversation that spurred this post.

Filed under:


(1) : MOSS Video, BSSw Honorable Mention, and The Maintainership Book I Am Writing:

Video

Mozilla interviewed me about the Python Package Index (PyPI), a USD$170,000 Mozilla Open Source Support award I helped the Python Software Foundation get in 2017, and how we used that money to revamp PyPI and drive it forward in 2017 and 2018.

From that interview, they condensed a video (2 minutes, 14 seconds) featuring, for instance, slo-mo footage of me making air quotes. Their tweet calls me "a driving force behind" PyPI, and given how many people were working on it way before I was, that's quite a compliment!

I will put a transcript in the comments of this blog post.

(Please note that they massively condensed this video from 30+ minutes of interview. In the video, I say, "the site got popular before the code got good". In the interview, I did not just say that without acknowledging the tremendous effort of past volunteers who worked on the previous iteration of PyPI and kept the site going through massive infrastructure challenges, but that's been edited (for brevity, I assume).)

This video is the first in a series meant to encourage people to apply for MOSS funding. I mentioned MOSS in my grants roundup last month. If you want to figure out whether to apply for MOSS funding for your open source software project, and you need help, ping me for a free 20-minute chat or phone call and I can give you some quick advice. (Offer limited in case literally a hundred people contact me, which is unlikely.)

BSSw

The Better Scientific Software (BSSw) Fellowship Program "gives recognition and funding to leaders and advocates of high-quality scientific software." I'm one of three Honorable Mentions for 2020.

The main goal of the BSSw Fellowship program is to foster and promote practices, processes, and tools to improve developer productivity and software sustainability of scientific code. We also anticipate accumulating a growing community of BSSw Fellowship alums who can serve as leaders, mentors, and consultants to increase the visibility of those involved in scientific software production and sustainability in the pursuit of scientific discovery.

Exascale Computing Project logoThat's why I'll be at the Exascale Computing Project Annual Meeting next week in Houston, so if you're there, I hope to meet you. In particular I'd like to meet the leaders of open source projects who want help streamlining contribution processes, growing more maintainers, managing communications with stakeholders, participating in internship projects like Google Summer of Code and Outreachy, expediting releases, and getting more out of hackathons. My consulting firm provides these services, and at ECPAM I can give you some free advice.

Book

And here's the project I'm working on -- why I received this honor.

In 2020, I am writing the first draft of a book teaching the skills open source software maintainers need, aimed at those working scientists and other contributors who have never managed public-facing projects before.

More than developer time, maintainership -- coordination, leadership, and management -- is a bottleneck in software sustainability. The lack of skilled managers is a huge blocker to the sustainability of Free/Libre Open Source Software (FLOSS) infrastructure.

Many FLOSS project maintainers lack management experience and skill. This textbook/self-help guide for new and current maintainers of existing projects ("brownfield projects") will focus on teaching specific project management skills in the context of FLOSS. This will provide scalable guidance, enabling existing FLOSS contributors to become more effective maintainers.

Existing "how to run a FLOSS project" documentation (such as Karl Fogel's Producing Open Source Software) addresses fresh-start "greenfield" projects rather than more common "brownfield", and doesn't teach specific project management skills (e.g., getting to know a team, creating roadmaps, running asynchronous meetings, managing budgets, and writing email memos). Existing educational pathways for scientists and developers (The Carpentries, internships and code schools) don't cover FLOSS-specific management skills.

So I'm writing a sequel to Karl's book -- with his blessing -- and I'm excited to see how I can more scalably share the lessons I've learned in more than a decade of leading open source projects.

I don't yet have a full outline, a publisher, or a length in mind. I'll be posting more here as I grow my plans. Thanks to BSSw and all my colleagues and friends who have encouraged me.

Filed under:


: What Does A Volunteer Development Coordinator Do?: A giant wall of text follows, giving a snapshot of work I do. I nurture the software community that supports the Wikimedia movement. So here's a big swath of stuff I did between February 1st and today.

Wrote and posted a blog entry about the San Francisco hackathon. Still need to do more followup with participants.

Handed over the MediaWiki 1.19 deployment communications plan to Guillaume Paumier, WMF Technical Communications Manager. He blogged a summary of the deployment and of our efforts and that's just the tip of the iceberg; he also set up a global message delivery and improved the CentralNotice maintenance message and did even more to make sure that we thoroughly communicate about the upcoming deployment to all the Wikimedia communities. I also shared information with various folks regarding testing of site-specific gadgets on 1.19.

I sent at least 285 work-related emails. That's 41 per workday but I definitely sent some work-related email on weekends.

Some patch queue work, responding to contributors and getting experienced developers to review the patches. I'm just trying to keep our queue from growing while code reviewers are mostly focused on getting MediaWiki 1.19 reviewed, polished, and deployed. But I do want to take care of all parts of the volunteer pipeline -- initial outreach and recruiting, training, code improvement, commit access, continued interest and participation, and debriefing when they leave -- so the patch review queue is a continuing worry.

Some work preparing for the Pune hackathon and for GLAMCamp DC, neither of which I am attending. I wrote or edited some tutorials and made a tutorial category which pleases me. We have more good material for workshops and stuff now, yay! And I helped the GLAMCamp people a bit in talking through what technical goals they wanted to achieve during the weekend.

Got dates from Wikimedia Germany for the Berlin hackathon, 1-3 June, and started trumpeting it. Also worked on planning for it and did outreach. For example, I reached out to about 13 chapters that are pursuing or interested in some kind of technology work like, say, funding or working on the offline Wikipedia reader (Wikimedia Switzerland), or usability and accessibility for Wikisource (Wikimedia Italy), or the Toolserver, a shared hosting service for tools and stuff that hackers use to improve or make use of the Wikimedia sites (for example, Wikimedia Germany & Wikimedia Hungary). We hope they can convene, share insights and collaborate at the WMDE hackfest.

Told at least 30 contributors to apply for Wikimania scholarships because the deadline is 16 February.

Talked to some Wikimedia India folks about planning technical events, and contributed to a page of resources for upcoming events.

Worked on some event planning & decisions for a potential event.

Passed the word to some friends, acquaintances, and email lists about some job openings at the Foundation.

Google Summer of Code has been announced, and I am managing MediaWiki's participation. I have started -- flyers, emails, recruiting potential students, improving the wiki page, asking experts whether they might mentor, and so on. I'm trying to start a thing where every major women's college in North America gets a GSoC presentation by March 15th, to improve the number of GSoC applications that come from women; let's see how that goes. MediaWiki still needs to apply to participate as a mentoring organization and acceptances only go out after that, but I'm comfortable spending time preparing anyway. And the women's college outreach will lead to an increase in the number of applications for all the participating open source projects, instead of just aiming a firehose at MediaWiki; that's fine. Like Tim O'Reilly says, aim to create more value than you capture.

Related to that -- I set up a talk for one of our engineers to give at Mills, a women's college that has an interesting interdisciplinary computer science program (both grad and undergrad, the grad program being mixed-sex) and I think it may end up being a really amazing talk. Ian Baker is going to talk about how CS helps us work in Wikimedia engineering, how we collaborate with the community during the design, development, and testing phases, and what skills and experiences come in handy in his job. I'll publicize more once there's an official webpage to point to.

Had a videoconference with a developer and my boss about our conversion to Git. I prepped for it by collecting some questions and getting preliminary answers, and then after the call we ended up with all this raw material and I sent a fairly long summary to the developers' mailing list. There's a lot left to do, and the team needs to work on some open issues, but we have a lot more detail on those TODOs now, so that's good.

Saw a nice email from Erik Möller publicizing the San Francisco hackathon videos and tutorials/documentation, yay!

Talked with a few people about submitting talks to upcoming conferences. I ought to write some preliminary Grace Hopper, Open Source Bridge, and Wikimania proposals this week.

Various volunteer encouragement stuff (pointing to resources, helping with installation or development problems, troubleshooting, teaching, putting confused people in touch with relevant experts, etc.), especially talking in IRC to eager students who want to do GSoC. Many of them are from India. I wonder how many of them see my name and think I'm in India too.

Commit access queue as usual.

Saw privacy policy stuff mentioned on an agenda for an IRC meeting on the 18th, so I talked to a WMF lawyer a little bit about privacy policy stuff for our new Labs infrastructure. We set up a meeting for this week to iron stuff out.

Helped with the monthly report. I have a colleague who wants to learn more about All This Engineering Stuff, so every month we have a call where I explain and teach the context of the report, and for this month's call I suggested we add another colleague who also wants to learn how the tech side works. Who knows, maybe this will turn into a tradition!

Followed up on the GSoC 2011 students who never quite got their projects set up and deployed on Wikimedia servers, and looks like two of them have some time and want to finish it now, yay! Updated the Past Projects page.

Checked in on the UCOSP students who are working on a mobile app for Wiktionary and told them about Wikimania, new mobile research, etc. Also got some feedback from their mentor, Amgine, on how they're doing.

Started an onwiki thread to discuss the MobileFrontend rewrite question(s).

Talked to Oren Bochman, the volunteer who's working on our Lucene search stuff, and followed up on a bunch of his questions/interests.

Ran & attended meetings.

Suggested to the new Wikimedia Kenya chapter that maybe we could collaborate, since they're interested in helping schools get Wikipedia access via offline reading.

Looked into the code review situation by getting a list of committers with their associated numbers of commits, reviews, and statuschanges. It's just a first pass, but it's a start for discovering who's been committing way more than they review, so we can start efforts to mentor them into more code reviewing confidence. I also saw who's been reviewing way more than they commit, and saw a name I wasn't familiar with -- looks like I've now successfully recruited him to come to the Berlin hackathon. :-)

Put two groups of people in touch with each other: did a group-intro mail to people at various institutions working on Wikimedia accessibility, and another to people who want to work on a redesign of mediawiki.org's front page.

And there was other miscellaneous stuff, but this is already sooooo TL;DR (too long; didn't read). (Which is funny because that's the name of my team.) Monday awaits!

Filed under:



[Main]

You can hire me through Changeset Consulting.

Creative Commons License
This work by Sumana Harihareswara is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available by emailing the author at sh@changeset.nyc.