Can I Take This Issue?

Related chapterOpen Source Etiquette: Talking to Strangers Who Owe You NothingSaying No: Five Replies That Keep Contributors Coming Back

Open-source software development is a collaborative effort that relies on volunteers. Contributors have different skill levels and come from various backgrounds, so maintainers make sure the contributions they receive are of high quality and meet the project’s goals. One way they do this is by providing clear guidelines on how to submit work. Unfortunately, contributors don’t always read these guidelines, and maintainers don’t always assign issues. That leads to confusion and frustration on both sides.

So Can I Take It or Not?#

This is a common scenario in open-source projects. A contributor sees an issue 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 go to the issue and take the time to answer something you may have already said ten times this week. You 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 ask if you can take it, and the maintainer says they don’t assign issues. You 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.

Why Do Some Maintainers Assign Issues?#

Maintaining an open-source project involves multiple responsibilities. One of them is managing the issues reported by contributors or users. Assigning issues to specific maintainers or contributors is a common practice. It helps address problems in a timely and efficient manner, and it keeps contributions aligned with the project’s vision and goals. Not all maintainers assign issues, though, and some only assign a small number of them.

Efficiency#

Assigning issues to specific individuals helps address them promptly, so fewer are overlooked or forgotten. It lets maintainers resolve issues in a timely and effective manner. 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.

Accountability and Responsibility#

Assigning issues helps clarify the responsibilities of different contributors and maintainers. When an issue is assigned to a specific person, it’s clear who is responsible for resolving it. This reduces confusion and makes sure the right people address the issue, especially in larger projects where many contributors and maintainers work simultaneously.

Assigning issues also creates a clear sense of accountability. The assignee becomes responsible for resolving the issue, which can motivate them to take ownership and work towards a solution. When contributors know they are responsible, they are more likely to focus their efforts on finding one. This sense of ownership can also lead to a more engaged and invested community.

Encouraging Contributions#

Assigning issues to specific contributors can encourage community involvement and collaboration. Assignees have a clear understanding of what needs to be done, which leads to more contributions and a more active community. Assigning issues can also encourage collaboration between contributors and maintainers, which leads 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 so contributors are aware of them. Maintainers can also provide feedback on contributions, highlighting areas for improvement and encouraging contributors to continue their work.

Better Resource Management#

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.

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

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

Avoiding Confusion#

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 make sure everyone knows their role in addressing the issue.

Why Do Some Maintainers Not Assign Issues?#

Despite the benefits of assigning issues, maintainers face some challenges. So some of them choose not to assign issues, quite a lot in fact. This can leave contributors not knowing what to work on or feeling discouraged about contributing to the project.

Limited Resources#

Maintaining an open-source project can be a daunting task, and a handful of maintainers often shoulder the responsibility. They review contributions, triage issues, and coordinate with contributors to ensure the project’s growth and success. Due to limited resources, some maintainers may not be able to assign issues effectively. That 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 for many maintainers it’s a voluntary and unpaid job. 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 prefer to focus their attention on other aspects of the project, such as code review or documentation. Some maintainers are also 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. Maintainers may be unable to keep up with the influx. The result is 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. It 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.

Large Communities#

As the community expands or is already large, maintainers may struggle to keep track of all its members and their capabilities. 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. 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. This is a time-consuming process, so some maintainers avoid assigning issues altogether. That 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, establish clear guidelines for issue assignment and make sure all members of the community are aware of them.

Collaborative Approach#

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.

This approach can be effective, but 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. 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 a rotating ownership model: issues are assigned to a specific contributor for a set period of time, after which ownership rotates to another contributor. This allows for individual ownership of issues while still promoting collaboration and knowledge-sharing.

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

Avoiding Favoritism#

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 give everyone a fair opportunity to contribute is to establish 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 allows contributors to work together in a coordinated fashion and avoid duplication of effort. In some cases, it may even create a sense of friendly competition amongst contributors, which can help to drive innovation and progress.

Maintainers can also provide feedback on contributions so everyone is working towards the same goal. That minimizes duplication of effort and confusion.

Trust Community#

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 effective 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 when 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.

Relying solely on the community to self-organize has 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. Maintaining open communication channels for contributors to ask questions or provide feedback can also help build a collaborative environment while still maintaining some level of oversight and direction.

Lack of Familiarity#

We may tend to forget it, but not all maintainers know everything about open source. Some of them may “choose” not to assign issues 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. Some maintainers may also 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 🙂

Hybrid Approach#

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. 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 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 using the contributions of others.
• Recruiting members of the community.
• Learning from the contributions of others and improving their own skills and knowledge.

How to Address the Issue of Not Assigning Issues#

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

Strong Workflow#

Projects that don’t assign issues often rely on a strong issues workflow. A good system of labeling and triage helps 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. The community can then be autonomous, and the maintainers, who most of the time have really limited resources, get less noise.

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.

With limited resources, maintainers can set up automatic triage systems that categorize and prioritize issues based on their severity or complexity. The community can then be autonomous and evaluate where they could be helpful depending on their level and expertise. Experienced contributors can tackle high-priority or high-complexity issues, or the core team can reserve them. Low-priority or low-complexity issues might be left for new contributors to help them gain experience.

Maintainers can also reach out to the community to encourage contributions and provide guidance on how to best help with the project. That makes it easier for contributors to get involved.

Labeling is very effective, 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. A template can include a checklist of requirements that need to be met before an issue can be treated, such as a clear description of the problem, steps to reproduce, or any relevant logs or errors messages. For a new feature, it can ask for the motivation.

• Description templates on GitLab
• Configuring issue templates on GitHub

As of September 2026, GitHub doesn’t provide any options to add some Markdown content at the end of the issues when using issue templates. The markdown elements of an issue form are shown to the author but not submitted. You can use GitHub Actions to do that, though. Here is an example of a GitHub Action that adds a message for newly created issues:

Open-reSource/
labs-append-markdown-to-issues[Labs] GitHub Action that 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. A new ready for dev label could then be applied combined to high priority and low complexity labels, and a version 12 label, bug or feature. Then core team if it is reserved for the core team, or pr welcome when it is OK for external contributors to work on it. Contributors can then start to help or not and 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 effective it can be.

Communicate Clearly#

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 a sense of community among contributors, which can lead to greater collaboration and more successful outcomes.

Clear guidelines and protocols for issues assignment, plus open communication with contributors, help each issue get addressed by the most qualified contributor. That leads 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.

The Importance of Contribution Guidelines#

Open-source projects need 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 the core team manages issues. It may or may not assign them to individual team members. The guidelines should also explain the reasons behind this approach. For example, issues need to be addressed in a timely and efficient manner, and 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.

Whatever approach an open-source project takes, 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, doesn’t it? ;)

Often, contributors don’t read the contributing guidelines#

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.

Even so, apart if the Contributing Guidelines are not at the right place, contributors don’t always take the time to read them. They may be in a hurry to start working on the project, or 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 so they don’t repeat the same information to the newcomers. Newcomers almost always ask the same things, from the streamer’s point of view. The streamers are not bothered while 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.

The key points:

• Make the Contributing Guidelines clear and easy to find. Make sure 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. Make sure 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. 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

Manual, Semi-automatic, and Automatic Tools#

Using a combination of manual, semi-automatic, and automatic tools, maintainers can manage the influx of questions from contributors who are unsure about taking up an issue. Contributors can then contribute effectively, and maintainers can focus on other aspects of the project.

Several manual and automatic tools can 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 maintainers handle it. They can engage with contributors who are unsure about taking up an issue and write down a specific personalized message. They can help clarify any confusion and make sure contributors feel supported to contribute in the right way. They can 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 good at 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.

On the contributor’s side, Finding a Project to Contribute To covers where to find an issue and how to start on it without wasting an afternoon. Open Source Etiquette covers the comment to write instead of “Can I take this issue?”.