[OH-Dev] Issue Management Migration to GitHub Issues

[Elana Hashman]

On Mon, Aug 04, 2014 at 09:19:54PM -0700, Asheesh Laroia wrote:
> Hey all,
> 
> It seems to me that there's at least a lukewarm consensus on moving to
> github issues.
> 
> Given that, Louis -- are you still interested in helping out with this? If
> you can do a fresh test import, we can sanity-check it, and then give you
> enough oh-mainline access to do the real import (or perhaps ask for the
> commands so I can do that myself).
> 
> I'm really excited about closing the loop on this.

I wanted to add my five cents (we don't have pennies up here in Canada 
anymore), but I wanted to wait for the migration to finish as I don't really 
have any better ideas to offer. I'm -0 on the whole migration.

First, a big thanks to Asheesh and Louis to completing all the work to get this 
done! I apologize in advance as I'm about to rain on your parade. :\

I do think there are benefits to the integration with our source hosting and 
PRs/code review, but there's a number of problems introduced. I'll separate 
them into workflow issues and ideological issues:

Workflow issues.

- Issue numbers have changed. This change was pretty jarring as I'm in the 
  crunch phase of a my GSoC project, for which I have been faithfully following 
  issue numbers as tracking items all summer. I and many others base branch 
  naming on issue numbers, and I've been referring to issues by number all 
  summer, so the change has introduced some inconsistency.

- The GitHub issue tracker is simply too minimal. The only identification 
  criteria we have for bugs now are labels, milestones, author, assignee, and 
  timestamp. There is no way to indicate relationships between issues 
  (predecessor/waiting on). There is no severity label, so we've lost the
  ability to auto-sort by urgency. Having already attempted to search for my 
  own issues (with difficulty), labels are too open-ended and introduce way too
  much noise imo. I think improved search was a cited feature over Roundup, but
  I'm finding the two to be basically on par.

- Bug creators/assignees did not get transferred over, and I can't go back to 
  the old Roundup instance to retrieve this info. So I've actually been having 
  a difficult time finding things I've reported and things that are assigned to 
  me.

- Last modified time was/cannot be transferred over as GitHub's last modified 
  time. This makes identifying recent/stale issues very difficult, and has 
  increased noise.


Ideological issues.

- GitHub is a closed platform. I'd like to move away from that if possible, 
  rather than towards it.

- I'm concerned about vendor lock-in. We appear to be moving more and more of 
  our stack to GitHub, and thus we are becoming more and more reliant on it. 
  A logical next step is migrating our wiki, given the cited benefit of having 
  everything in the same place. This reduces the maintenance burden of 
  self-hosting free solutions but also makes us increasingly reliant on GitHub 
  as a platform, and may make it harder to move away later if we choose to do 
  so.

- The issue of GitHub as a safe and supportive company has been raised. Just 
  months ago, we were discussing moving our source off the platform. But now we 
  are migrating more things onto it! This concerns me.


Anyhow, thanks again to those taking the initiative to improving our issue 
workflow! Roundup certainly has a lot of problems, and the integration between 
our tracking issues and pull requests/code reviews could be a lot better.

Hope you find my thoughts useful,

--
Elana Hashman
elana at hashman.ca