OPTIONS

Choose A JIRA Ticket

JIRA is the system we use to track feature requests, bug reports and other requested work. Each project has an associated JIRA project:

Guidelines for Choosing a Ticket

Anyone can file a JIRA ticket, and some tickets may be vague, underspecified, or out of date. Some tickets may be feature requests that cannot or will not be implemented because the request may be incompatible with planned changes or is a feature that would have a greater negative impact than positive.

The following lists some guidelines to help you choose a ticket:

  1. Choose a ticket that is unassigned.

  2. Do not choose a ticket with Fix Version “Features we’re not sure of” or “Needs triage”. “Needs triage” is the default fix version for new tickets. Both of these versions indicate that we haven’t decided how the ticket will fit into our roadmap.

  3. Aim for a ticket with Fix Version of the next version. For example, if the current stable release is 2.6, you want to aim for something in the “2.7 desired” fix version.

  4. Choose a ticket with detailed and specific description. A more thorough specification improves your chances of implementing the changes in a non-breaking way.

  5. Avoid tickets with debates over the implementation details in the comments. Approvals are less likely for changes based on a controversial tickets.

  6. Look for tickets without any or fewer cross-dependencies. A ticket that has numerous links to other tickets, depends on other tickets, or have other tickets depend upon it require more research and can be difficult to implement correctly without being in close contact with the persons implementing the others tickets.

    If you’re just starting out, try to pick a ticket that has fewer cross-dependencies.

  7. Verify approval of New Feature requests. To avoid feature creep, requests for New Feature undergo a review and approval process. If choosing a New Feature request ticket, verify that we have approved the request.

Scope Consideration

It is important to keep your changes to the scope of the JIRA ticket. This helps us accurately track changes.

For instance, do not correct typos or trailing whitespace or anything else outside of the scope of the ticket. If your IDE of choice has auto-formatting, turn that feature off.

If you go outside the scope of the ticket, your changes are unlikely to be merged.

SERVER-Specific JIRA FAQs

  • What do the JIRA ticket Fix version numbers mean?

    A server roadmap/master plan covers all the tickets that have undergone comprehensive review.

    We break down specific versions into subcategories. Ordered from most to least pressing, these are:

    1. <Version> Desired (for whichever is due out next, e.g. 2.7.)
    2. Planning Bucket A
    3. Planning Bucket B
    4. Planning Bucket C
    5. Planned But Not Scheduled
    6. Features We’re Not Sure Of
  • What does the #neweng label mean?

    This label exists for tickets that we think are a good entry point for engineers who are new to the codebase. The tickets are small in scope, provide a good learning experience, and/or are otherwise appropriate for a new server contributor.

  • Is there any way to get feedback on the ticket I picked?

    Yes. Once you have picked a ticket, you can email the mongodb-dev mailing list to get feedback on your chosen ticket. This mailing list is specifically for anyone interested in contributing to the database or building third party tools around and is a great resource for feedback throughout the process of contributing to the server.