Enabling Github Issues for Infusion project

Thu Jan 9 19:04:42 UTC 2020

They did announce improved integration between JIRA and GitHub. It appears that this is maintained by GitHub so should work well ( https://github.blog/2018-10-04-announcing-the-new-github-and-jira-software-cloud-integration/ <https://github.blog/2018-10-04-announcing-the-new-github-and-jira-software-cloud-integration/> ). However, it appears that it requires the Cloud hosted version of JIRA. I believe we can apply for a free cloud account, but there would be some work to migrate. 

Thanks
Justin

> On Jan 9, 2020, at 12:35 PM, Colin Clark <colinbdclark at gmail.com> wrote:
> 
> Wouldn’t it be nice if people could just use their Github accounts to log into JIRA? I did some searching but didn’t see any apparent signs that they offer a “Login with your Github Account” feature.
> 
> Colin
> 
>> On Jan 9, 2020, at 11:30 AM, Ned Zimmerman <nzimmerman at ocadu.ca> wrote:
>> 
>> Reflecting on Colin's questions: before I worked for the IDRC I was looking for a place to file issues for Infusion (when Pressbooks was exploring an implementation of UIO), and the necessity of having to sign up to add JIRAs prompted me to just email Jonathan instead (sorry Jonathan!). I could see the value for other developers/designers who already have a GitHub account in being able to file an issue on GitHub and then have it automatically moved to a JIRA, with the end result looking something like this: https://probot.github.io/apps/move/
>> 
>> In other words, the issue would be filed using someone's existing GitHub account, and they would be given a link to the corresponding JIRA. If they wanted to get more involved they would have to sign up there, but they could get the ball rolling on GitHub.
>> 
>> Another example: WordPress uses Trac for tickets and patches. It can be quite cumbersome for less technical users, particularly when it comes to adding patches to tickets. A WordPress community member made this integration (https://rmccue.io/patch/) which lets users open a PR on the WordPress GitHub mirror (https://github.com/WordPress/WordPress) and then submit the changes as a patch to a given Trac ticket. The pull requests are automatically closed. It's a fairly simple tool that helps people get involved with a lower barrier to entry.
>> 
>> I do feel like a mass migration of tickets could be a lot of work, even setting aside concerns about centralizing within GitHub. However, I could see the benefits in supporting some kind of integration.
>> 
>> Cheers,
>> Ned 
>> —
>> Ned Zimmerman
>> Senior Inclusive Developer
>> Inclusive Design Research Centre, OCAD University
>> https://idrc.ocadu.ca
>> 
>> On 2020-01-09, 9:15 AM, "Colin Clark" <colinbdclark at gmail.com> wrote:
>> 
>>   Hi Jon,
>> 
>>   Yup, that makes sense. I think Antranig’s response was more about the specific proposal of doing a large scale migration away from JIRA. We’re a small community with a lot of ambitious work ahead of us, so lo-fi, low intervention solutions seem best. 
>> 
>>   I think it would be fine to set up Github issues if you think it’s a lot easier. It might be worth thinking through first where most people are starting from: are they developers who probably already have GitHub accounts, or are they more end users who might not? Do they tend to find UIO and Infusion on Github, or from our website, or linked from a tutorial or video walkthrough, or via npm? The one risk to opening up Github Issues as a new and separate place to file issues is that people might be confused by the relative lack of activity. They’d go there perhaps thinking they could see what issues are active or commonly-occurring, but end up seeing not very much.
>> 
>>   Are there specific usability issues you think people are commonly facing with JIRA? Could It be set up to avoid those particular problems? I know Simon and Michelle have done a lot of work to create very custom and simplified workflows there for C2LC. 
>> 
>>   Or are we talking about more of a direct user support issue? The mailing list? More tutorials or FAQs? Improvements the Fluid website?
>> 
>>   I hope these are thoughts are helpful,
>> 
>>   Colin
>> 
>> 
>> 
>>> On Jan 9, 2020, at 10:23 AM, Jonathan Hung <jhung at ocadu.ca> wrote:
>>> 
>>> I am *NOT* suggesting migrating Jira to Github Issues and have Github Issues as a primary bug tracker.
>>> 
>>> I propose that the project consider Github Issues another avenue for community engagement with Jira remaining the primary bug tracker as always.
>>> 
>>> 1. Treat Github Issues as a low(er) barrier way for users to file bugs and support tickets.
>>> 2. Project maintainers and community members would be responsible for monitoring and supporting Github Issues and migrate any valid issues to Jira.
>>> 
>>> The fundamental issue right now is that many integrators outside of our immediate community are not using IRC or Jira to communicate with the project. Enabling Github Issues can help improve communication, support, and adoption.
>>> 
>>> Would this be palatable?
>>> 
>>> -----Original Message-----
>>> From: fluid-work <fluid-work-bounces at lists.idrc.ocad.ca> On Behalf Of Antranig Basman
>>> Sent: January 9, 2020 10:02 AM
>>> To: fluid-work at lists.idrc.ocad.ca
>>> Subject: Re: Enabling Github Issues for Infusion project
>>> 
>>> It would be a terrible idea to migrate our issues to Github issues. As well as all of the work implied onto our community, which is much less well resourced than the Spring Framework, we face the burden of rewriting all the links to JIRAs which are held in numerous places in other tools and resources. As well as all of this entirely unnecessary work, we then run the risk of having this vital piece of infrastructure out of our control and instead under the control of a corporate entity - Microsoft. Having our code in github is reasonable since there is a reasonable migration path out - simply clone the repository. Having our issues in github issues is a much greater level of exposure.
>>> 
>>> Cheers,
>>> 
>>> Antranig.
>>> 
>>>> On 08/01/2020 23:30, Gregor Moss wrote:
>>>> Hi all,
>>>> 
>>>> I think there’s value in keeping all of our issue tracking and related communications in the same place. 
>>>> Indeed, having those in the same place as our code seems to make even 
>>>> more sense! We wouldn’t need to concern ourselves with either keeping 
>>>> everything lined up manually or maintaining a set of actions to 
>>>> transfer everything over and then update the relevant GitHub issues 
>>>> whenever progress is made. We would also gain the ability to have commit comments like “Closes #50” rather than having to manage webhooks to close/reopen issues with pull requests.
>>>> 
>>>> Furthermore, GitHub is a website that has a much larger userbase and 
>>>> higher traffic rate than our own Jira site(s), so in terms of 
>>>> attracting new participants to our work it might be a better choice to 
>>>> migrate to GitHub. We also wouldn’t need to worry as much about spam 
>>>> accounts. In eliminating our Jira sites, we also eliminate the need to 
>>>> support them. Of course that also means we’re beholden to GitHub and Microsoft and their licence agreements, though I don’t see this as much worse than depending on Atlassian for working software.
>>>> 
>>>> One thing to consider: would Confluence play as nicely with GitHub as 
>>>> it does with Jira? I.e. if I wanted to link an issue in the Iteration Plan, do we lose anything in terms of functionality?
>>>> 
>>>> The Spring Framework migration that Justin shared is promising, and it 
>>>> looks like the timestamps from comments were also preserved.
>>>> 
>>>> Lastly, as the Spring notes allude to, the markup issue is one we’ll 
>>>> have to deal with, though we’re currently experiencing issues with that anyway so I don’t see this as much of a factor.
>>>> 
>>>> I’d love to know your thoughts on these arguments! I don’t have a 
>>>> strong preference, but if we’re going to do anything at all, moving things to GitHub makes the most sense to me.
>>>> 
>>>> Cheers,
>>>> 
>>>> Gregor
>>>> 
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca To unsubscribe, change settings or access archives, see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
>>> To unsubscribe, change settings or access archives,
>>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>   _______________________________________________________
>>   fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
>>   To unsubscribe, change settings or access archives,
>>   see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>> 
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20200109/1f15b2cb/attachment.html>