Proposal for simplification of the code contribution process


Here is a proposal to further simplify the OSS code contribution process and bring it at par with the contribution process followed by other/popular open source projects.

The proposal is to no longer require code-contributions to have an issue-tracker (Jira) id associated with it.

This means:

  1. A code contributor would directly raise a Pull Request and fill in the PR template with details about the code change.
  2. There would not be any requirement to associate the PR with a JIRA id (existing or new). (One is however free to associate an existing (or create a new one) Jira ticket.)
  3. The test logs that were earlier required to be attached to the Jira ticket would now have to be attached to the pull request itself.
  4. Any interface/design changes will continue to have to be presented in the project documentation area and discussed in the community forums.

The above has the following impact on the Pull Request /git-commits:

  1. The PR template will be modified to drop the PP-XXX field. (anybody wishing to reference a PP-XXX ticket can still do it in the body of the PR/description).
  2. The commit-ids will simply contain a description of the issue being fixed, and not start with "PP-XXX: ".
  3. Design documents (EDDs), community discussions and the Pull Requests will be linked via web-links to each other.

Please let us know of your feedback/thoughts on the above proposal.


I always thought (and think so even now) that having JIRA ticket associated with a PR helps in better tracking of the changes that go in. JIRA ticket is kind of go-to place to know about the change, type of change, the issue that is being resolved, links to the documentation, forum discussion etc…
Is the plan to make PR as the place to get all that information and scrap JIRA in the long run?


The proposal is not to go scrap Jira. We will have open jira and that will remain the OSS bug tracking system. However, like other open source projects, we would not be required to mandatorily have a jira-id before some code can be contributed. If you look at most open source github repos, this is the way they work. The pull requests completely describe what is being done. Contributors would be free to add more information into (new/existing) jira ticket(s) if they want.

To give you an example of how few other open source projects looks like do have a look at these large projects:


I like this proposal – it should simplify a lot of cases without losing any information.

In particular, if someone has a fix for a bug, they can simply submit the pull request with all the info – there’s no need to duplicate the info in a JIRA ticket. (JIRA is still useful when someone finds a bug … and doesn’t have a fix… yet.)


Since we are simplifying the code contribution process can we consider github issue tracker instead of Jira if it has all the capabilities that we care?

It is easy to refer the existing issue in the PR (#issuenumber will do it).

Proposal: GitHub Issue Tracker (versus current Jira)

+1 for GitHub issue tracker…

Proposal: GitHub Issue Tracker (versus current Jira)

I like the idea of using GitHub issue tracker, but don’t care for having JIRA in addition. We should probably stick with one or the other, not both. I do favor the GitHub issue tracker route for OSS.

Proposal: GitHub Issue Tracker (versus current Jira)

I vote for Github Issues as well, but am a bit concerned about how existing tickets will be migrated from JIRA to Github Issues.

I like the overall idea that you proposed Subhasis.

Proposal: GitHub Issue Tracker (versus current Jira)

I think migrating from JIRA to GitHub issue won’t be a much problem as both has API which we can make use of to migrate using some sort of script…
When I search on internet and I find this

Proposal: GitHub Issue Tracker (versus current Jira)

I like the overall proposal. Just want a clarification, it doesn’t matter which issue tracker we choose, github or JIRA, it would still not be mandatory for contributing code correct? (except for the cases where there is a bug but no fix )


Yes Anamika, irrespective of the choice of the issue tracker, the proposal is to NOT mandate that a issue be referenced as part of a pull request.


Thanks for all the great feedback. We will implement this proposal soon.


BTW, I like the github issue tracker over jira (aside from this proposal). The challenges i can think of are:

  1. Migrating existing bugs.
  2. Updating the merged PR’s which had references to Jira tickets: Do we go and update those references to the github issue tracker references. Or, we make the existing jira issue tracker read-only so the references are intact (for the old PRs), but any new activity happens in github issue-tracker (this could be confusing to users anyway)…

Proposal: GitHub Issue Tracker (versus current Jira)

I agree that it would be confusing, especially if we create a Github Issues copy of it, so maybe this is another thing that needs to be taken care of while migrating, and if that’s not easy to do, then maybe it’s not worth it.

Proposal: GitHub Issue Tracker (versus current Jira)

Why migrating existing bugs? Why not just phase out JIRA and start using Github issue clean?
Keep the references to JIRA issues for old PRs, and for all new PRs use Github issue.

Proposal: GitHub Issue Tracker (versus current Jira)

Exactly @minghui. I was suggesting the same. We can use github issues from clean state. That would mean that we continue to keep our current Jira repo around, perhaps in read-only mode (just as a reference for older PR’s that reference Jira).

Proposal: GitHub Issue Tracker (versus current Jira)

This is a good discussion (and a fine proposal) – I have started a new thread at Proposal: GitHub Issue Tracker (versus current Jira).

Matching the topic of discussion with the topic subject helps ensure good visibility among the community, and it allows people to use the per-topic notification features of the forum without worrying about missing important discussions.


As there has been no further comment since the above (about a month ago), let’s go ahead and implement this. (I am also closing this topic.). Thx!