This site is an archive; learn more about 8 years of OpenHatch.

[OH-Dev] Issue Management Migration to GitHub Issues

Carol Willing willingc at willingconsulting.com
Mon Aug 11 14:42:34 UTC 2014


Elana raises some good points about GitHub Issues.

Here's an article by Ian Bicking which I found helpful:
http://www.ianbicking.org/blog/2014/03/use-github-issues-to-organize-a-project.html

On the ideological issues:
I am also not comfortable with all eggs in a GitHub basket. Yet, I don't 
have any better alternatives to offer here. It probably is a prudent 
path to use github-issues features that are accessible via API so that 
data can be extracted if/when the time comes to adapt again to a new 
tool for issue tracking.

On the workflow side:
Changed issue numbers - Perhaps there is a way to update the migrated 
issues to have some reference to the old Roundup Issue number (maybe 
appending to issue title?).
Bug creators/assignees & last time modified for Roundup issues - Perhaps 
a message can be appended to the GitHub issues that captures this 
information as an issue comment. The comment would be searchable via GitHub.
GitHub Issue flexibility and search - Like gmail with its tags, GitHub 
Issues has similar flexibility and power through its labels. I have seen 
some sites (why can't I find one now?) that use labels and color quite 
effectively. Searching with multiple labels selected does a pretty good 
job. That said, the OpenHatch oh-mainline labels will likely evolve over 
time to meet the issues that Elana raises.

Thanks to Asheesh and Louis and the OpenHatch team for moving the issues.

Carol




On 8/10/14, 8:30 PM, Elana Hashman wrote:
> 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
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel


-- 
*Carol Willing*
Developer | Willing Consulting
+1 760 456 9366 | https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20140811/81f9b001/attachment.html>


More information about the Devel mailing list