Migrating from Jira to GH Issues

[R.A. Porter]

There has been some discussion about moving from Jira to GitHub issues for DDF and Alliance. New repositories have, for the most part, been using GH Issues instead so we have some small amount of data so far and have been pleased with what we see. Some other open source projects have also been making this move with great success.

Amongst the advantages are the following:

• Better integration with GH Pull Requests
  
• The ability to use GH Projects with triggers setup to help automate ticket workflow
  
• Unlimited access and visibility; Jira technically has no cap on users but as we reach each user threshold there is a non-trivial process to have the max raised
  
• With the purchase of GH by Microsoft, there is a strong sense that the tooling - which has already improved a good deal in the last year or two - will become ever more robust and feature-rich

This short post from the Accumulo Apache project on their decision to migrate and their approach lays out a simple way forward (https://accumulo.apache.org/blog/2018/03/16/moving-to-github-issues.html). Rather than attempting to migrate existing Jira issues over to GH Issues, only those issues that are to be worked are copied over and linked back. New issues are exclusively added in GH, and Jira eventually reaches its functional end sooner. This provides the dual advantages of spring cleaning issues and being able to make the jump once a decision has been reached without any complex migration processing.

We could likely configure Jira to be read-only at the time of migration with a header link to GH Issues to avoid any inadvertent issues being created there.

I think this issue warrants discussion and debate. In my eyes, it's the right move to make but I may be failing to consider some important technical or governance issue.

- Richard

[vinama...@gmail.com]

JIRA will continue to exist in read-only format, right? If so, +1

[R.A. Porter]

That's the intent, yeah. We'd probably keep it around long-term for historical reasons, even if there were no more issues in it that were ever to be picked up.

[vinama...@gmail.com]

Should we wait until another DDF release to switch over? That we way can assume that any tickets that need a bug fix are already released and can use github issues now?

Or is it relatively trivial to still link back to JIRA tickets?

[Jason Smith]

I have not done a ton of research on GH issues, but from what I have seen, their biggest shortcoming is project management.  It doesn’t appear there are nearly as many options for boards, workflows, ticket config, and reporting as JIRA.  That being said, I don’t know that we have a strong need of any of these features in Codice.  Given that, I’m in agreement to give GH issues a try.  Aligning the switchover with the next DDF release seems reasonable to me.

 

• Jason

--
You received this message because you are subscribed to the Google Groups "ddf-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ddf-developer...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aaron Hoffer]

Sounds interesting. Having better integration between change requests to pull requests would be nice. It looks like Github project boards would let Codice developers have a kanban board. 

Maybe 1-2 week pilot with a particular group of developers would be useful? It might better expose the pros and cons of the move.

[R.A. Porter]

Another example of a project - a significantly larger project with far more history - making the move: https://spring.io/blog/2019/01/15/spring-framework-s-migration-from-jira-to-github-issues

I respect the commitment of the Spring developers to migrate the entire history over but I believe it is overkill for Codice projects. Others may differ.

This post goes into a lot of details about the reasoning and advantages of the move as well as a bit on the migration process itself and is worth at least a cursory read for all interested in this topic.

-Richard

[Ethan Manns]

My concern with this is that we'd be coupling our issue tracking to our repository hosting. If in the future we ever decided to migrate our code to another hosting service, we'd be forced to do another migration of our existing issues. This is pretty speculative, since to my knowledge that isn't being considered right now, but I think it's worth keeping in mind.

On Wednesday, January 16, 2019 at 1:15:42 PM UTC-7, R.A. Porter wrote:

[R.A. Porter]

That's a very reasonable point and not one for which I have a definitive answer. All the pros of coupling issues and project tracking to source control definitely become cons if you decide to migrate source.

I'm pretty confident we'll be sticking with GH for the foreseeable future, but a few supporting voices from PMC members would help assuage any minor concerns on that front.

-Richard

[Keith Wire]

Github added project boards to help organize and prioritize work.

 

https://help.github.com/articles/about-project-boards/

 

--Keith

 

From: ddf-dev...@googlegroups.com <ddf-dev...@googlegroups.com> On Behalf Of R.A. Porter
Sent: Friday, January 18, 2019 8:36 AM
To: ddf-developers <ddf-dev...@googlegroups.com>
Subject: Re: Migrating from Jira to GH Issues

 

That's a very reasonable point and not one for which I have a definitive answer. All the pros of coupling issues and project tracking to source control definitely become cons if you decide to migrate source.

--

[Phillip Klinefelter]

Given the way issues and PRs are worked on DDF, I can see the advantage of requiring one less login to contribute.  It should also help automate the closing of tickets once they are finished.

https://help.github.com/articles/closing-issues-using-keywords/

I don't think it has been mentioned yet but we should also consider migrating DDF wiki content to the DDF GitHub wiki area.

[R.A. Porter]

Yep. We're in fact using them on a couple of our Codice repos already

• https://github.com/codice/saml-conformance/projects/1
  
• https://github.com/codice/acdebugger/projects/1
  

[R.A. Porter]

It seems like there's general consensus, with no one expressing any show-stopping concerns, that this is worth a pilot test for DDF and/or Alliance. Based on the low volume of change on Alliance right now, I'd suggest DDF is the better choice.

We've released 2.13.5 quite recently, so it might be a good time to start.

My gut feeling is that in some cases, PRs that are well written and documented will be sufficient without an associated Issue. This would be the case for basic bug fixes, doc changes, dependency upgrades, and the like where the engineer was going to quickly go in and make a smallish change that would require no design discussion, threat modeling, or other architectural considerations. Where discussion or design back-and-forth would be necessary - particularly with new features - we'd definitely want an Issue. We'd also want Issues when an engineer (or user) wanted to report a bug or request a change without intending to do the work themselves/immediately.

Does everyone agree that, say, Monday 28 January is a good day on which to cut over for a pilot? If we run it for two to four weeks, we won't have too many issue to port into Jira if we decide it's not for us. If at or near the end of the pilot we decide it's working, we can lock down Jira to be read-only at that time.

I could be mistaken, but I don't think running this pilot should require a PMC vote. If I'm wrong (which a PMC member will quickly let me know), we can open a vote and push out the potential start date for the pilot until the first Monday after the voting window.

-Richard

On Wednesday, January 16, 2019 at 1:15:42 PM UTC-7, R.A. Porter wrote:

[Phillip Klinefelter]

This would be a significant procedural change so it does seem vote worthy.  I think this thread has been enough to get a lazy consensus to try the pilot.  I am ok with doing a formal vote at the end of the pilot as long as no one else in the PMC disagrees.

Richard, can you write guidelines we can use during the pilot on the DDF wiki?  I enabled the wiki on Github. 

https://github.com/codice/ddf/wiki

https://codice.atlassian.net/wiki/spaces/DDF/pages/71946981/Pull+Request+Guidelines

https://codice.atlassian.net/wiki/spaces/DDF/pages/37552149/JIRA+Primer+Best+Practices

[Patrick Ouellet]

One issue I can see with having a PR created without an issue is that it now prevents us from prefixing commit messages with the related ticket/issue number which was a really useful addition to commits when looking at gitlog for various reasons (e.g. later back port or forward ports of fixes). Your only way out is to use GitHub to find associated commits. Sometimes using git tools on the command line is really useful.

Patrick

[vinama...@gmail.com]

This is actually an interesting point as this is how I primarily use tickets/blame currently.

Will we lose pre-pended ticket #s? 

[R.A. Porter]

Good point, Patrick. I think a solution to that (that is only mildly annoying) is to use the PR number as the commit prefix. It's mildly annoying because it would require the submitter to rename their commit after creating the PR in order to update it with the generated id.

Contrasted with the mild annoyance of creating an Issue for super-trivial work, I suspect most engineers would choose the commit-rename mild annoyance.

-Richard

On Wednesday, January 23, 2019 at 10:10:23 AM UTC-7, Patrick Ouellet wrote:

[Patrick Ouellet]

So, assuming that people have installed the githooks as they should), they would be forced to put a dummy PR number first or XXXX and then later not forget to update that commit with the actual PR number.

 

This seems to me like something that will be often forgotten.

 

I would prefer always have an issue first created even if that is a simple one.

 

Patrick

 

From: <ddf-dev...@googlegroups.com> on behalf of "R.A. Porter" <richard...@connexta.com>
Date: Wednesday, January 23, 2019 at 10:22 AM
To: ddf-developers <ddf-dev...@googlegroups.com>
Subject: Re: Migrating from Jira to GH Issues

 

Good point, Patrick. I think a solution to that (that is only mildly annoying) is to use the PR number as the commit prefix. It's mildly annoying because it would require the submitter to rename their commit after creating the PR in order to update it with the generated id.

[R.A. Porter]

I am personally indifferent to it and think it's just one more thing for committers to validate but I don't have a strong opinion one way or the other. We could always require Issues for PRs.

I'll post guidelines for the pilot on the Wiki prior to Monday morning, hopefully before the weekend.

-Richard

[Phillip Klinefelter]

Github adds the PR number to the commit message when you merge a PR.  Here is what I get from a git log --oneline.

5bee31339c DDF-4423 Upload Editor Reads 100% Before All Files Uploaded (#4171)
316bb66d86 DDF-4430 updated the IdP to allow it to renew expired assertions (#4179)
8cf569f64a DDF-4432 CRLF for solr.cmd (#4238)
c3a5a904c7 DDF-4468 Adds migration:import warning message and force option (#4239)
788feec7f6 DDF-4435 upgraded UI dependencies to silence warnings (#4187)
48d001fc2c DDF-4393 Temporal attribute values in filter template JSON are not being normalized to the expected date format (#4127)
9c68f5959d DDF-4120 remove unused dependency (#4194)

Those links are clickable on GH. 

https://github.com/codice/ddf/commits/master

But you can copy that number from the commit message from the command line and open it with https://github.com/codice/ddf/pull/<# from commit message>.  The only difference is that we would drop the issue prefix and just use the existing PR postfix.

[vinama...@gmail.com]

The important thing there is to make sure contributors describe the problem in the PR template and not just the solution. That way we have a context to refer back to that is separate from the solution.