Enabling Github Issues for Infusion project

Fri Jan 10 14:24:35 UTC 2020

Hi, All:

To answer Colin's question, there is a third party plugin that is meant to
add support for logging into to JIRA using GitHub credentials:

https://marketplace.atlassian.com/apps/1211397/openid-authentication-for-jira?hosting=server&tab=overview

It's free for open source and available for hosted environments like ours.

Cheers,

Tony

On Thu, 9 Jan 2020 at 20:05, Justin Obara <obara.justin at gmail.com> wrote:

> 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/ ).
> 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
>
>
> _______________________________________________________
> 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/20200110/5fbcf9d2/attachment.html>