Last updated 2 November 2016.

Who are new contributors?

New contributors are knowledgeable about their areas of interest but they might not be familiar with the Drupal core contribution tools and process. And, some will be new to Drupal as well. New contributors might be site builders, developers, writers, designers, and so on.

We use the word "Novice" to identify potential tasks for these new contributors.

Why novice tasks?

Tackling a real task on a real Drupal core issue that is doable in a short period of time will give new contributors a chance to learn the Drupal contribution tools and process without having to focus on challenging intellectual problems. A good novice task gives people a first successful contribution experience and empowers new contributors to move on with other issues in the future.

What makes a good novice task?

The best tasks for new contributors should allow contributors to learn and get comfortable with contribution tools (local development stack, drupal.org, Git, IRC, etc.) without too many distractions.

  • Good novice tasks have clear steps and are not open-ended.
  • Keep the scope of tasks specific.
  • Choose issues that you understand.
  • Always check to make sure issue tags (Needs steps to reproduce, Needs manual testing, etc.) are still accurate. If the tag is no longer accurate, remove it and look for a different issue.

One issue has many tasks

Note that the entire issue does not have to be novice. One core issue consists of many tasks done by different contributors. Identify specific tasks within an issue that are small, well-defined, and actionable.

Time estimates

If you are an experienced contributor, a guideline you can use is to estimate how long you think the task would take you to complete. The majority of the tasks you select should be in the 0–30 minute range for an experienced contributor. It’s okay to select a few longer tasks if they meet the criteria above, but if it looks like a significant undertaking to you, it might not be a good novice task.

Task types

Task types in the contributor tasks guide are often good choices for new contributors, because they have clear instructions and are needed for many issues. For core mentoring, see the core contribution mentoring task chart, which groups common Drupal core tasks by the skillset required to complete the task.

Tasks for sprints

Pick tasks that a new contributor can complete during the sprint. “Project” or “homework” tasks (those that would take several weeks of IRC mentoring) don’t usually make good tasks for new contributors at sprints (though they may work for regular and experienced contributors). Keep in mind that many people will not return to the issue for various reasons.

Sprint priorities

Ask “priorities?” in the core contribution mentoring backchannel. Talk to sprint leads or task selection leads about priorities for the sprint.

What tasks or issues should be avoided?

Tasks to avoid (#)

Sometimes, a task is not a good choice for a new contributor even if it is one of the recommended task types. Avoid:

  • rerolls of large patches (50KB is probably pushing it) or patches that touch many files, because learning how to resolve merge conflicts takes experience
  • issue summaries of issues with many comments or rocky histories, because can be discouraging for new contributors
  • upgrade path tests, because they are more difficult and time consuming than most web tests.

Issues to avoid

Some issues are not ideal for new contributors, even if there are potential tasks that need to be done for the issue. Avoid issues that are:

  • urgent, because new contributors need extra time
  • long, because they can be overwhelming
  • contentious or lacking consensus, because new contributors might be misdirected or get stuck in the middle of a debate
  • reopened, derailed, or shifting direction, because they can be very confusing.
  • postponed, because people new to the issue queue might search for just the Novice tag and not know to filter to active issues. We should focus on quality actionable novice tasks, and not worry about having "a lot" of them.
  • versions not under development, because we want new contributors to work on issues that are important and of interest to other people, so their work gets reviewed, and they have interaction with others. We should not mark Drupal 6, 8.1.x, 9.x issues as Novice. Focus on 8.0.x (or 7.x) issues.
  • issues devoted to coding standards: see Coding standards below. A task to fix coding standards on a larger issue is fine.

Also avoid issues that are probably not committable during the current release cycle phase, because new contributors will not see the results of their work for a long time. These issues include:

  • significant feature requests after feature freeze
  • minor feature requests when we are significantly over issue thresholds
  • issues for 8.1.x or 9.x before the release of 8.0.0
  • significant API or data model changes after the first beta release
  • minor data model changes once the beta-to-beta upgrade path is supported
  • minor API changes later in the beta phase.

(Un)tagging novice issues

Any issue which has at least one novice task can be tagged "Novice". This includes, for instance, complicated issues which need manual testing and before/after screenshots added to the issue summary. (It can happen that experienced contributors disagree with an issue being tagged "Novice", in which case they may be pointed to this document.)

Specifying individual tasks

Dreditor adds an "Insert Novice tasks" button to the "Issue summary" section. This button inserts an HTML table with most rows commented out, for your convenience, after which you can

  • read through the commented lines and uncomment the appropriate ones;
  • adjust or add descriptions as appropriate, if none really fits;
  • delete or add "Novice" from the Novice? column;
  • update the Complete? column for tasks already done (maybe reference the comment number where they were done);
  • add any standard "Needs" tags that exist for tasks you uncomment (e.g. "Needs screenshot" or "Needs issue summary update"; see "Needs" tags).

Use your own judgment to see if the issue summary itself should be updated to make the tasks clearer, and/or some task details should be specified in the comment you are adding (example). This is partly influenced by whether "update the issue summary" itself can be a novice task.

Triaging issues for sprints

Larger sprints are usually prepared by tagging issues with a dedicated tag. Consensus is to use tags without spaces or hashes, starting with a capital e.g. "Amsterdam2014". At the time of writing there is a fork/pull request for Dreditor which can automatically tag all edited issues, so people doing triaging cannot forget to actually add the tags: http://build2be.com/content/using-dreditor-triage-issues

Untagging novice issues

It is important for issues which have the "Novice" tag but have evolved to not have any novice tasks anymore, to be untagged. This saves work for everyone who is triaging issues in the future. While untagging, you could reference this documentation page containing guidelines for what are novice tasks.
If you untag an issue which took non-trivial time to judge, it is still OK for a sprint specific tag to be added to this issue. (These tags are used to track work invested for sprints, and this is.)

Coding standards: it's complicated

It is important to make sure that new patches do not introduce violations of coding standards, but generally avoid looking for issues to fix existing problems, since these get contentious and may not get committed. Wait until we have automated tests for coding standards, so we can make sure such issues stay fixed. See [meta] Make Core pass Coder Review.