Issue tracking

Justin Obara obara.justin at gmail.com
Mon Jul 6 13:10:16 UTC 2020


Hi Tony,

Thanks for the feedback. Personally I find that it can be confusing, at least in the context of Infusion, because we have JIRA components related to Infusion components that are included in an Infusion release and others that aren’t (e.g. website). That makes using JIRA’s versioning semantics confusing, and means that you can’t use the version semantics for the components that do not share the same release as Infusion.

Sorry that paragraph in itself is confusing, but hopefully you understand what I mean.

We’ve have also created more JIRA projects <https://issues.fluidproject.org/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all>, although those also tend to correspond to actual projects we are working on and not so much with independent repos. Although sometimes that’s the case.

I find that tracking the issues alongside the code is easier for those joining the community and just making use of a repo. It also allows for versioning, milestones and etc to be specific to the code base being released/developed. 

I’m curious to hear more of your thoughts, especially because you’ve used both systems. Also please let me know if there are workarounds or workflows to address the issues I’ve mentioned about JIRA.

Thanks
Justin


> On Jul 6, 2020, at 8:52 AM, Tony Atkins <tony at raisingthefloor.org> wrote:
> 
> Hi, Justin.
> 
> When working on the GPII JIRA instance I simply set up a component for each repository and tracked things in the main GPII project.  We might do something similar, handle them as components within the FLUID project on issues.fluidproject.org <http://issues.fluidproject.org/>.  Particularly for the plugins used in linting/testing Infusion itself, it would make linking easier, especially since we also get issue/PR linking via JIRA's DVCS plugin.
> 
> That being said, I do use GH issues for other work, and am not opposed to it in general.
> 
> Cheers,
> 
> 
> Tony
> 
> On Mon, 6 Jul 2020 at 14:35, Justin Obara <obara.justin at gmail.com <mailto:obara.justin at gmail.com>> wrote:
> I’ve added the recently migrated repos to the Google Sheet <https://docs.google.com/spreadsheets/d/1xKLW8rQC-JN-TI9sL0ojeLXNRoqk4DfPwFd51jAuRJo/edit?usp=sharing>. I assume that at least some of these were being tracked in the GPII Jira <https://issues.gpii.net/secure/Dashboard.jspa> instance. It might make sense to migrate these over to GitHub Issues, and if so could be a good place to start looking into that process. 
> 
> Please let me know what you think.
> 
> Thanks
> Justin
> 
>> On Jun 4, 2020, at 9:20 AM, Justin Obara <obara.justin at gmail.com <mailto:obara.justin at gmail.com>> wrote:
>> 
>> Hi Everyone,
>> 
>> I haven’t heard any opposing views to my proposal below. I’m taking silence as consent and have moved forward with the first phase, which is to catalogue the issue tracking for the public repos in the fluid-project <https://github.com/fluid-project> and inclusive-design <https://github.com/inclusive-design> GitHub orgs.
>> 
>> I’ve created a Google Sheet <https://docs.google.com/spreadsheets/d/1xKLW8rQC-JN-TI9sL0ojeLXNRoqk4DfPwFd51jAuRJo/edit?usp=sharing> which includes a list of the repos and mentions the Issue Tracker(s) that are currently being used. Please review and leave comments about the repos. Pay particular attention to any that you are working on now, have worked on in the past, or will be working on in the future. Also please provide feedback on the need for repos. There are many cases where it appears the repo can be archived or completely removed. And there are many repos where it isn’t clear what they are used for. Please make sure to fill out the descriptions in the repos appropriately.
>> 
>> Notes on the Google Sheet: 
>> 
>> Archived Repos: I have highlighted the row and indicated “TRUE” in the “Archive” column. For these archived repos, we do not need to do anything, as there is no active work.
>> If there is no “Current Issue Tracker(s)” listed, that means I was not able to find evidence of any issues filed against that repo based on commits. There may be an active GitHub Issue tracker, however no Issues have been filed.
>> 
>> Thanks
>> Justin
>> 
>>> On Feb 24, 2020, at 9:23 AM, Justin Obara <obara.justin at gmail.com <mailto:obara.justin at gmail.com>> wrote:
>>> 
>>> Hi Everyone,
>>> 
>>> This topic was touched upon in a recent "Enabling Github Issues for Infusion project <http://fluid.2324889.n4.nabble.com/Enabling-Github-Issues-for-Infusion-project-td10666.html>” Fluid-Work mailing-list thread. However, what I’m proposing here is slightly different from that particular discussion so thought it best to move off into a new thread.
>>> 
>>> TL;DR: Use GitHub issues for repos that don’t have their own JIRA space
>>> 
>>> The problem:
>>> 
>>> A couple of things that I personal find confusing and/or have seen others trip over are: 
>>> That a repo has GitHub issues active and is also tracked in JIRA (e.g. the floe project website - GitHub Issues <https://github.com/fluid-project/floeproject.org>, JIRA <https://issues.fluidproject.org/issues/?jql=project%20=%20FLOE%20AND%20component%20=%20%22FLOE%20Website%22>)
>>> That a project/repo is tracked in a JIRA space but doesn’t follow the same release and versioning. (e.g. fluid-publish <https://issues.fluidproject.org/issues/?jql=project%20=%20FLUID%20AND%20component%20=%20fluid-publish>)
>>> 
>>> Proposal:
>>> 
>>> Use Fluid JIRA project only for Infusion. Move other repos/projects to other JIRA projects or GitHub issues as needed
>>> When migrating issues from between JIRA spaces or GitHub issues, the existing issues should be migrated as well
>>> Use GitHub Issues for existing repos that do not have a corresponding JIRA project
>>> Use GitHub Issues for new repos, unless/until there are features and etc needed that aren’t supported by GitHub issues but are available in JIRA, at which point a new JIRA project should be created.
>>> For projects/repos that use JIRA, GitHub issues should be disabled and information provided in the README and/or other appropriate location to indicate that issues are tracked in JIRA.
>>> 
>>> The previous thread also discussed having JIRA and GitHub issues synced together, or migrating everything to GitHub Issues from JIRA. I’m not intending to weigh in on those questions with this proposal. I’m taking this from the point of view of how things are currently being done. If one or more of those other suggestions/proposals are accepted, my suggestions above can be modified as needed. In general I want to reduce the confusion that may be happening in our issue trackers at the moment.
>>> 
>>> Thanks
>>> Justin
>>> 
>>> 
>> 
> 

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


More information about the fluid-work mailing list