Can I Take This Issue?

Open-source software development is a collaborative effort that relies on volunteers to contribute to the project. Contributors have different skill levels and come from various backgrounds. As such, project maintainers have a crucial role in ensuring that the contributions received are of high quality and meet the project’s goals. One way maintainers do this is by providing clear guidelines on how contributors can submit their work. Unfortunately, contributors don’t always take the time to read these guidelines, and maintainers don’t always assign issues, which can lead to confusion and frustration on both sides. In this article, we’ll explore the issue of unassigned contributions and discuss what can be done to address it.

This is a common scenario in open-source projects. A contributor sees an issue that they think they can solve, so they ask if they can take it.

If you are the maintainer of this open-source project, you start by receiving a notification. You then go to the issue and take the time to respond to the contributor something you may have already said ten times this week. You then go back to your work, and receive another notification from the same contributor saying basically “OK thanks!“.

If you are the contributor, you may feel frustrated. You may have spent time looking for an issue to work on, and you may have even started working on it. You then ask if you can take it, and the maintainer responds by saying that they don’t assign issues. You then feel discouraged and decide not to contribute to the project.

This is a frustrating experience for both the contributor and the maintainer.

The contributor is left wondering if they can actually work on the issue, and the maintainer is left wondering why the contributor didn’t read the contributing guidelines.

Maintaining an open-source project is a challenging task that involves multiple responsibilities. One of them is managing issues reported by contributors or users. Assigning issues to specific maintainers or contributors is a common practice that can help ensure that problems are addressed in a timely and efficient manner and that contributions align with the project’s vision and goals. However, not all maintainers assign issues, or they may only assign a small number of them. In this part, we will explore the reasons why some maintainers choose to assign issues and what are the benefits of assigning issues.

Assigning issues to specific individuals helps ensure that they are addressed promptly and efficiently, reducing the likelihood of issues being overlooked or forgotten. It allows maintainers to manage issues more efficiently, ensuring they are resolved in a timely and effective manner. However, the assignee can still benefit from the feedback of the community and maintainers, and this approach is particularly useful for larger projects that receive many issues.

Assigning issues can help to clarify the responsibilities of different contributors and maintainers. It’s clear who is responsible for resolving an issue when it’s assigned to a specific person. This can reduce confusion and ensure that issues are addressed by the right people. In larger projects, where multiple contributors and maintainers may be working simultaneously.

Assigning issues can also create a clear sense of accountability and responsibility. When an issue is assigned to a specific person, they become responsible for resolving it. This accountability can motivate contributors and maintainers to take ownership of the issue and work towards a solution. When contributors know that they are responsible for resolving an issue, they are more likely to focus their efforts on finding a solution. This sense of ownership can also lead to a more engaged and invested community.

Assigning issues to specific contributors can foster community involvement and collaboration. Assignees have a clear understanding of what needs to be done, leading to increased contributions and a more active community. Additionally, assigning issues can encourage collaboration between contributors and maintainers, leading to more efficient issue resolution and a stronger sense of community.

To address unassigned contributions, both contributors and maintainers need to work together.

Contributors can help by taking the time to read the project’s contribution guidelines carefully. They should also review the issue tracker and try to find issues that align with their skills and interests. If an issue is not assigned, contributors can reach out to maintainers or community managers for guidance.

Maintainers can also take steps to address unassigned contributions. One way is to review the issue tracker regularly and assign issues promptly. They can also update the contribution guidelines and make them more visible to ensure that contributors are aware of them. Maintainers can also provide feedback on contributions, highlighting areas for improvement and encouraging contributors to continue their work.

Assigning issues can also help to manage resources more effectively.

By assigning issues to specific contributors or maintainers, the workload can be distributed more evenly. It also helps prevent duplicated work, as contributors can see what others are working on and avoid duplicating their efforts.

Assigning issues can also help maintainers to manage their workload. By assigning issues to specific people, maintainers can ensure that they are not overwhelmed with too many tasks at once.

This approach can help to prevent burnout and ensure that contributors and maintainers are working on issues that are within their skill level and expertise. It can ensure that maintainers’ time and energy are focused on the issues that matter most.

Assigning issues can also help to avoid confusion. When multiple people are working on the same issue, it can be difficult to know who is responsible for what. By assigning issues to specific people, maintainers can ensure that everyone knows what they are responsible for and what their role is in addressing the issue.

Despite the benefits of assigning issues, there are also some challenges that maintainers may face. So there are some maintainers who choose not to assign issues, quite a lot in fact. This lack of assignment can result in contributors not knowing what to work on or feeling discouraged about contributing to the project. In this part, we will explore the reasons why some maintainers do not assign issues, or sometimes only a small amount of them.

Maintaining an open-source project can be a daunting task, and the responsibility is often shouldered by a handful of maintainers. These maintainers are responsible for reviewing contributions, triaging issues, and coordinating with contributors to ensure the project’s growth and success. However, due to limited resources, some maintainers may not be able to assign issues effectively, which can lead to frustration among contributors and a decline in the project’s growth.

Maintaining an open-source project requires a significant amount of time and effort, and it can be a voluntary and unpaid job for many maintainers. As such, they may not have the financial resources or personnel to manage every issue that is reported.

Assigning an issue without proper analysis and discussion is inadequate and can impede its development. This is especially true for issues coming from the community, as they may lack sufficient details. Prioritizing, analyzing, and discussing the issue is necessary before assigning it to a maintainer or contributor for resolution. Assigning issues to specific people requires time and effort, and some maintainers may prefer to focus their attention on other aspects of the project, such as code review or documentation. Furthermore, some maintainers may be juggling multiple projects or other commitments in their personal and professional lives, which can limit their ability to assign issues.

They are often already too busy reviewing contributions. Open-source projects are often community-driven, and they can receive a large number of contributions, especially when they gain traction. Each contribution requires review, testing, and integration, which can be time-consuming, especially for maintainers who have other responsibilities. In such cases, maintaining the project can become a daunting task, and maintainers may be unable to keep up with the influx of contributions, leading to a backlog of unassigned issues and sometimes even unassigned pull requests.

The issue tracker can become overwhelming, making it difficult to assign issues to the right people. The issue tracker serves as a central hub for the project’s issues, feature requests, and pull requests. As the project grows, the number of issues and pull requests can quickly pile up, leading to confusion on the part of contributors. Without proper triaging and assignment, contributors may not know what to work on or feel discouraged about contributing to the project, resulting in a decline in contributions.

As the community expands or is already large, maintainers may struggle to keep track of all its members and their capabilities. In such cases, assigning issues can become a daunting task, as maintainers may be uncertain of the skill level and commitment of potential contributors. Junior developers and new open source members may be attracted to issues in already popular projects, seeking mentorship and opportunities to contribute, but this can overwhelm maintainers who cannot mentor everyone or have limited resources for reviewing contributions.

To assign issues appropriately, maintainers may need to review past contributions, evaluate code quality, and reach out to potential contributors to discuss their interest in the project. However, this can be a time-consuming process, leading some maintainers to avoid assigning issues altogether. This can create a backlog of issues that go unaddressed, causing frustration among contributors.

And this approach can backfire, as it can create a backlog of issues that are not being addressed, which can cause frustration among contributors. In such cases, it is essential to establish clear guidelines for issue assignment and ensure that all members of the community are aware of them.

Some maintainers believe that assigning issues can create silos and discourage collaboration. They may prefer to have an open forum where anyone can contribute to resolving issues. This approach allows the community to work together and share knowledge and expertise. They encourage contributors to take ownership of the project and work together to resolve issues, rather than relying on a single maintainer to manage all aspects of the project.

While this approach can be effective, it can also result in a lack of direction and oversight. Without clear guidance or leadership, contributors may not know what to work on or how to approach a particular issue.

To address this, maintainers can provide clear documentation on the project goals and how to get involved. Additionally, they can establish communication channels for contributors to ask questions or provide feedback, or even encourage contributors to work in pairs or small groups to resolve issues. Another potential solution is to use a rotating ownership model, where issues are assigned to a specific contributor for a set period of time, after which ownership of the issue rotates to another contributor. This approach allows for individual ownership of issues while still promoting collaboration and knowledge-sharing.

By doing so, maintainers can foster a collaborative environment while still maintaining some level of oversight and direction.

Assigning issues can also lead to accusations of favoritism or bias. Some maintainers may choose not to assign issues to avoid any perception of preferential treatment. By allowing anyone to work on any issue, maintainers can ensure that everyone has an equal opportunity to contribute. This approach can help to create a more inclusive and welcoming community, where all contributors are valued and respected.

However, this approach can also result in confusion and duplication of effort. If multiple contributors are working on the same issue, it can lead to wasted time and resources.

One way to ensure that everyone has a fair opportunity to contribute to a project is through establishing clear guidelines and protocols for contribution. For instance, the project can have a clearly defined process for claiming issues, stating who is responsible for which tasks, and how contributors can go about resolving issues. This approach allows contributors to work together in a coordinated fashion and avoid duplication of effort. In some cases, it may even foster a sense of friendly competition amongst contributors, which can help to drive innovation and progress.

They can also provide feedback on contributions to ensure that everyone is working towards the same goal, thus minimizing duplication of effort and confusion.

Another reason why some maintainers do not assign issues is that they trust the community to self-organize and take ownership of issues without assigning them to specific individuals. This approach is based on the belief that a highly engaged and motivated community will work together to resolve issues and prioritize tasks. It can be an effective approach in projects with a large and active community where multiple contributors can work on the same issue simultaneously.

When maintainers trust the community to self-organize, they can focus on other aspects of the project such as developing new features, maintaining documentation, or mentoring new contributors. This approach can also be useful in situations where maintainers have limited resources or are unable to keep up with the volume of incoming issues. By allowing the community to take ownership of the project, maintainers can create a sense of ownership and belonging within the community, leading to increased participation and collaboration.

However, relying solely on the community to self-organize can also have its drawbacks. Without clear guidance or leadership, contributors may not know how to prioritize tasks or resolve issues effectively. Sometimes, the issues are not yet read by the maintainers and contributors start the development of something useless which is not what the maintainers want. This can result in duplication of effort, wasted time and resources, and may lead to frustration and disengagement among contributors.

To address these issues, maintainers can establish clear guidelines on how to claim an issue and work on it. They can also provide feedback on contributions to ensure that everyone is working towards the same goal. Additionally, maintaining open communication channels for contributors to ask questions or provide feedback can help foster a collaborative environment while still maintaining some level of oversight and direction.

We may tend to forget it but not all the maintainers know everything about open source so some maintainers may “choose” not to assign issues simply because they are not familiar with the process. Assigning issues can be a complex task, especially in large projects with many contributors. If a maintainer is not comfortable with the process, they may choose to avoid it altogether. Additionally, some maintainers may be new to the project and may not yet have a good understanding of the various roles and responsibilities. This can make it difficult to assign issues to the appropriate parties.

In this case, this article may be a good starting point 🙂

An open-source project can be maintained by a core team working full-time, often linked to a company. Then, issues assignments may be handled differently than in other open-source projects. Indeed, they can rely on a specific agenda and deadlines, so they may assign issues to ensure accountability, clear ownership, prioritization, expertise, and consistency. At the same time, the core team may also allow external contributors to contribute to the project for diverse perspectives, community building, increased productivity, and learning opportunities. In that case, they could not assign issues to external contributors. Here comes our hybrid approach.

As an external contributor, you won’t probably be assigned to an issue for several reasons:

• The issue must be tackled soon and they can’t rely on an outsider to deliver a specific task with a deadline.
• The issue requires extra internal information the contributor can’t have access to or internal discussions that happened or will happen and are not tracked, or won’t be tracked in the repository.

However, it might happen, depending on their contributing guidelines, for unprioritized issues that don’t have any deadline yet. Most repositories use a dedicated label in this case to let know outsiders that they can help and contribute. And of course, they will probably be happy to review code not related to already planned issues or fixes.

By allowing external contributions to the project, the core team might benefit from:

• A wide range of new perspectives and ideas.
• Building a community around the project.
• Increasing productivity by leveraging the contributions of others.
• Recruiting members of the community.
• Learning from the contributions of others and improving their own skills and knowledge.

Not assigning issues is a choice made by the maintainers based on several criteria as seen in the previous sections.

To counter-balance the fact that issues are not assigned, projects often rely on a strong issues workflow with a powerful system of labeling and triage to help identify the complexity of the tasks, the status of the analysis, whether the issue is ready to develop or not, the target versions, the scope, etc. so that the community can be autonomous, but also to reduce the noise for the maintainers who have most of the time really limited resources.

This full backlog can be accompanied by a schema representing the whole workflow of states of issues and sometimes even pull requests, the actors, etc. It can be linked to a roadmap.

To make the most of their limited resources, maintainers can set up automatic triage systems that categorize and prioritize issues based on their severity or complexity so that the community can be autonomous and evaluate where they could be helpful depending on their level and expertise. High-priority or high-complexity issues can be tackled by experienced contributors or reserved for the core team while low-priority or low-complexity might be left for the new contributors to help them gain experience.

Additionally, maintainers can reach out to the community to encourage contributions and provide guidance on how to best help with the project so that the whole process runs smoothly. By doing so, maintainers can ensure that they are making the most of their limited resources, while also making it easier for contributors to get involved.

Labeling is very powerful as it can filter the backlog by elements but also be used for automation in projects.

Everything can start from the creation of these issues with the issues templates to guide contributors in providing the necessary information when they create an issue. This can include a checklist of requirements that need to be met before an issue can be treated, such as providing a clear description of the problem, steps to reproduce, any relevant logs or errors messages, or motivation if this is a new feature.

• Description templates on GitLab
• Configuring issue templates on GitHub

At the time of writing, GitHub doesn’t provide any options to add some Markdown content at the end of the issues when using issue templates. However, you can use GitHub Actions to do that. Here is an example of a GitHub Action that adds a message for newly created issues:

Open-reSource/
labs-append-markdown-to-issues

[Labs] Automatically append Markdown to issues

An infinite way of managing labels is possible. Let’s imagine, for example, a “to analyze” label that can be picked up only by a core team member. When this core team member analyzed the issue and provided expectations, clarity, and guidance, the label could be transformed into an “analyzed” label, and a new “ready for dev” label could be applied combined to “high priority” and “low complexity” labels, and a “version 12” label, “bug” or “feature”, “core team” if it is reserved for the core team, or “pr welcome” when it is OK for external contributors to work on it. When doing that, contributors can start to help or not, filter the backlog by labels, and the core team can focus on the most important issues. If the workflow is automated, the issue can go to one or another project, be in a roadmap, etc. This is just an example, but you can imagine how powerful it can be.

By establishing clear communication channels, maintainers can provide guidance to contributors and answer any questions they may have about the assignment process and issues workflow. This can also help build trust and foster a sense of community among contributors, which can lead to greater collaboration and more successful outcomes.

By taking the time to establish clear guidelines and protocols for issues assignment and maintaining open communication with contributors, maintainers can help ensure that each issue is addressed by the most qualified contributor, leading to more successful outcomes for the project as a whole.

Whether maintainers put in place a simple or advanced workflow, it must be clearly explained somewhere. Depending on the amount of information, it can be directly in the Contributing Guidelines or in a Wiki, documentation, etc. linked from the Contributing Guidelines.

If issues are assigned, make sure that it’s clearly explained in the Contributing Guidelines.

If issues are not assigned, make sure that it’s clearly explained in the Contributing Guidelines.

Yes, it is important for open-source projects to have Contributing Guidelines to provide critical information about the project, including its goals, coding standards, how to submit changes, how to ask for help, and how to get involved in the community.

This is also the place where are explained how contributors can report issues and how maintainers will manage them. The guidelines should include information on whether issues will be assigned or left unassigned, and why. This will help to set expectations for both contributors and maintainers and ensure that everyone is on the same page.

If an open-source project is maintained by a core team working for a company, the contribution guidelines should make it clear that issues will be managed by the core team and may or may not be assigned to individual team members. The guidelines should also explain the reasons behind this approach, such as the need to ensure that issues are addressed in a timely and efficient manner, and the fact that the core team has the expertise and resources to manage the project effectively.

If an open-source project is maintained by a community of volunteers, the contribution guidelines should explain how issues will be managed and whether they will be assigned or left unassigned. The guidelines should also provide guidance on how contributors can help to manage the issue tracker, such as by reviewing and triaging issues, and how they can get involved in the project’s decision-making process.

Regardless of the approach taken by an open-source project, it’s important to have clear and transparent contribution guidelines that set expectations for both contributors and maintainers. This will help to ensure that the project is sustainable and that issues are addressed in a timely and efficient manner. On top of explaining what is the process, it is also interesting to explain why this choice has been made by the maintainers. It will help contributors who will read the contributing guidelines, but can also be useful to remind this rule for those who don’t read the contributing guidelines. It happens sometimes, isn’t it? ;)

First of all, contributors may not even know their existence. Always remind that each day, there are newcomers in the open source world who don’t know how it works. But let’s be honest, apart if the Contributing Guidelines are not at the right place, contributors don’t always take the time to read them because they may be in a hurry to start working on the project, or because they assume that their previous experience will suffice.

So the frustration of maintainers can be understood rather easily, especially if they spent time writing down a thorough explanation of why the repository doesn’t assign issues. Reminding days after days for years that the repository doesn’t assign issues feels like repeating over and over the same thing. But always remind that you are not talking to the same person who has a different background regarding OSS and probably does not have the same expertise as you in the field.

Streamers, for example, use pre-defined messages, videos, or FAQs in order not to repeat the same information to the newcomers (who almost always ask the same things based on the streamer’s point of view) so that they are not bothered when they are streaming, and the viewers can still have the information. Having tools answering for you, either semi-automatic or automatic, will help not become angry at contributors after repeating the same thing over and over.

In a nutshell:

• Make the Contributing Guidelines clear and easy to find. Ensure that they are prominently displayed on the project’s website, README file, in the documentation, in the issues templates, etc. Make sure they are easy to read and understand, with clear instructions on how to contribute and how the issues are handled in the global workflow.
• Communicate clearly with contributors. Even if it is mentioned everywhere, always remind nicely this information to the contributors who make mistakes. Provide clarity and guidance.
• Be consistent. Ensure that the rules for assigning issues are consistent across the project and that all maintainers are aware of them. This can help prevent confusion and ensure that all contributors are treated fairly. Having a unique reference stored in only one place is really handy because maintainers will be able to link this reference instead of reinterpreting the content every time, and maybe not being consistent. Plus, it’s always true even if the reference changes.
• Consider revisiting the guidelines. If you find that many contributors are not following the guidelines, it may be worth revising them to be clearer or to better reflect the needs of the project. However, be sure to communicate any changes clearly to existing contributors and provide guidance on how to adjust their contributions accordingly.

Overall, the key is to be patient, clear, and helpful in your interactions with contributors. By doing so, you can create a welcoming and productive community around your open-source project

Overall, by using a combination of manual, semi-automatic, and automatic tools, maintainers can help to manage the influx of questions from contributors who are unsure about taking up an issue. This can help to ensure that contributors are able to contribute effectively and that maintainers can focus on other aspects of the project.

There are several manual and automatic tools that maintainers can use to help handle these questions and politely refuse them by mentioning the contribution guidelines.

Direct communication is not really a tool, but this is often the way it is handled by maintainers. They can engage with contributors who are unsure about taking up an issue, write down a specific personalized message, help clarify any confusion and ensure that contributors feel supported and empowered to contribute in the right way, and even provide alternative issues or areas of the project where the contributor can help. But it takes a huge amount of time, especially in a big community, and the content can be inconsistent.

In most of the Git source code platforms, it is possible to set up saved replies:

• Comment templates on GitLab
• Using saved replies on GitHub

It is only a semi-automatic tool but it can help save a lot of time by not repeating over and over the same thing. Maintainers will lose the personalized side but will gain consistency with a clear and precise answer accompanied by links pointing to unique resources.

If you are maintaining OSS projects or communities on different platforms, you may opt for decentralized messages and actions stored in your own environment for transversal usage. Tools like Alfred on macOS could be used in this spirit.

Writing this article was the occasion to try creating a semi-automation tool based on labels. Maintainer can add a “we don’t assign issues” label to an issue right after a comment asking to be assigned. This label will trigger a GitHub action that will write a personalized comment explaining that the repo is not handled that way, and then remove this label automatically. We could even hide the original contributor’s comment in the process.

The source code of this experiment is available on GitHub via the card below.

Open-reSource/
labs-we-don-t-assign-issues

[Labs] "we don't assign issues" label that writes a comment and is then auto-deleted

Unfortunately, if there are intermediate comments before maintainers have the time to use this label, it won’t work. And it stays semi-automatic.

This was a nice experiment, but can we go further with full automation? Actions can already be triggered when a comment is created or updated, it would only be a matter of time to create a bot that would be able to answer automatically to the contributor.

We keep seeing new AI tools popping up every day in our feeds. They are pretty powerful and help automation. But so far, we haven’t had the occasion to find or test such tools for this specific use case. If you have any suggestions, or links, you can create an issue so that we can test them and improve this article. Or come talk about it on our Discord.

Found something valuable in this article?
Dropping us a star on GitHub would show your support and help others discover it.

Found a typo, a grammar error or a broken link? This article is missing something important?
Edit this article or create an issue for this article on GitHub.

CC BY-NC-SA 4.0 2023-2024 © Open {re}Source