Enabling Github Issues for Infusion project

[Jonathan Hung]

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