The great enforced work-from-home experiment that arose from the COVID-19 crisis has seen many businesses proclaim themselves to be ideally set up to hit targets and achieve results in a remote model. While this may be true for the short term or for small teams, the best place to look for a tested and true example of long-term remote work success is in the development of open-source software.
If your organization has been thinking about new projects but is stalled due to the uncertainty around resources and teams, it is worth looking at kicking off open-source initiatives because they have always functioned in exactly the model that we are all working in right now.
We’re open-source evangelists who have been building our eCommerce company in this mold for over a decade—including as the creators of Vue Storefront, the world’s fastest-growing open-source eCommerce frontend. We’ll share some best practices that will help you run successful open-source projects which bring together hundreds of independent people working across multiple time zones on critical processes.
Communication in open-source projects
It may seem obvious but you must have an effective communication framework up and running. However, I don’t just mean tooling like Google Meet, JIRA, and Slack. It’s equally important to have a set of ground rules so things don’t get messy.
The Vue Storefront team use GitHub issues as a backlog tracker where milestones are set with tickets assigned. We also use GitHub labels to set the additional categorized information about the tickets. For example, a “P0-Urgent” label means that the ticket must be done ASAP. “5: Complex” is a label signifying the complexity/time consumption of a single issue. This way, we can blend planning and prioritization together, without needing to use complex JIRA workflows.
The VSF team also uses Slack. And I’m talking about a huge community of 3,000 people on the dedicated channel. We have divided the Slack workspace into different channels to make it less confusing. For example, the #development channel is for thoughts on how Vue Storefront should be developed as a product and issues/ideas regarding the core. As a lot of people, especially newcomers, use Slack to get onboarded, we’ve got a dedicated #help channel. In fact, it’s probably one of the most vibrant channels we have and users have started helping each other without any centralized authority.
The core team uses the same tools as the community. In community projects, it’s important to be on the same page, not to have any hidden agenda.
Despite the fact that Slack gathers the community in one place, we set a rule that no decisions are made on Slack itself. They need to be confirmed in a kind of Github RFC (‘request for comments’ issue) or an e-mail to avoid non-precise decisions, lost information, and so on.
With a remote setup, you must also fight pre-made assumptions. For example, putting a plan in 10 bullet points is always better than just a note saying “We’ll fix performance in the next release”. The clarity of information and intent is key to keeping everyone pulling in the same direction.
One way to ensure this is to make an Issue tracker named >the only source of truth< for the roadmap and, if possible, all product information.
At some point we’ve added a forum to our communication landscape. This was a dual-purpose action:
- It has some SEO value to have the questions positioned in the search engines
- It cleans up the GitHub stream of questions not related to the product core
Self-explanatory tasks in an open-source project
People working remotely very often do things asynchronously—especially when they’re in different time-zones. They very often don’t have a chance to ask for more information, so we learned very quickly that we need to be very specific and put a lot of contextual information within the tasks we created on GitHub. There is usually even some idea of how the given task should be implemented.
The most important aspect is the Acceptance Criteria and reference materials. These two features will let the folk taking care of this task find more info even when there’s nobody to ask.
We’ve even got a template where you cannot miss these key parts of a new feature request or a bug report.
Product planning and statuses
The whole network of contributors (around 186) and partners (80+) is managed by a relatively small core team (around 6 people, though it depends how you count because we’ve grown from a single project to a whole ecosystem). The Core team has been used to working remotely from day one and has used Slack for daily communication and Hangouts for weekly product status meetings.
We keep notes in Confluence, though it could be Google Docs or Notion. Whatever you use, it should be a collaborative, online tool. We put notes after every meeting with all the decisions and action points.
We don’t use JIRA but we do Confluence. The most important thing about making decisions is to document them. We have a log of the meetings with all the action points, and decisions in a single wiki space.
We learned this the hard way, after a few months of making quick decisions online as questions arose via Slack or over calls. We strongly recommend against it once you have more than a couple of people on a project, as things quickly get too complex.
Our product management process is now a moderated forum. The product streams are synchronized but every team has a lot of space to make their own decisions. This is the only way for smaller teams to effectively build the products. If you make them wait for the results or decisions of each other’s work, it stops the whole machine working. Your process must be async-friendly. You can set the direction but teams need to set their own goals.
Make the onboarding easy and fun
If you’re looking for volunteers and they work remotely, it’s very important to get them onboard as soon as they show interested in your project.
We’ve started with a “README.md” with all set of links to the docs and installation procedure for the project and then a “CONTRIBUTING.md” file which includes all the info on how to pick your first issue, how to create a Pull Request, and where to find help.
There is also a whole range of issues marked as “Good first issue”. These are generally easy to execute and are mostly bug-fixes or minor feature requests. They are tasks that let new folks contribute something meaningful within two or three hours.
We’ve also sent official Vue Storefront t-shirts and hoodies. It was great to then see all the contributors to the project wearing them on the Hangouts meeting. It builds a kind of emotional engagement which is especially difficult to achieve in remote-only setups.
It’s all about ownership and fun
When you’ve got people on a payroll, you might ask them to just do things. In open-source, it doesn’t work that way. It doesn’t work that way, in general. In fact, in an ideal scenario, you should have your people wanting to do the things you haven’t even got a chance to ask them about yet!
For us, it is all about the ownership. If somebody says “Maybe I’ll do feature XYZ”, we’ve always been very open and enthusiastic about it. We never said, “Well, that’s a great idea but maybe John will take care of it”. Ownership is far more important than experience, position in the team, or anything else etc. It’s a quite rare and delicate factor that is usually a signal of future success.
We’ve been offering a lot of coaching in the Code Review process or RFC process. We sometimes ask people to maybe do a reality check with the users before implementing the whole thing. It’s about adding even more ownership. We then always put credits within the release notes, even for very minor contributions. Ownership means responsibility and commitment from the contributor and must be met with appreciation in return.
Giving feedback in open-source projects
Giving Feedback is difficult even in friendly, face-to-face conditions—especially when the feedback is critical. In remote setup, it can be even harder.
I suggest not passing on any negative feedback in written-only form. Slack and e-mail are not ideal but a GitHub comment is by far the worst option as it’s visible to all other contributors. It’s far better to have a call and discuss things first, then maybe put some constructive action points in a wrap-up email. Be positive and, moreover, constructive with the feedback you give people.
Open-source development is a people business
Building a community has taught us that open-source projects are a people business. If possible, you should do some face-to-face catch-ups with the team. We’ve been doing a lot of hackathons around the globe (over 20 per year at the peak). People had a chance to meet us personally, ask questions, and drink a beer together.
We’ve also had live, full-remote webinars in a kind of Ask Me Anything format. These helped close the gap and put everyone on the same page. I think this kind of open communication is very important in a remote setup. People don’t catch you at the watercooler and these all-hands sessions give much more chance to get the important questions answered.
Summary
If you’ve been thinking about kicking off an open-source project but have been hesitating, now is the time. It’s a tried and tested way of developing that fits the state of the world right now. I hope some of the tips and lessons learnt I’ve shared here will be useful.
We’re also still willing to learn from others, so we’d love to hear your experiences. What’s your way of getting things done remotely? Tell us what works for you.
The post Remote project management: Lessons from a decade as an open-source leader appeared first on Divante.com Blog.
from Divante.com Blog https://ift.tt/2XnZQar via IFTTT
No comments:
Post a Comment