Issue tracking

Tony Atkins tony at raisingthefloor.org
Mon Jul 6 14:16:42 UTC 2020


Hi, Justin.

I do know what you mean, the previous project that spawned these libraries
really wasn't able to take advantage of clear versioned JIRA releases in
general, so it was less of a concern there.  I'm happy to track issues in
the repository's GitHub issues and talk about it if the other side (linking
to/from JIRA) becomes more of a concern.

Cheers,


Tony

On Mon, 6 Jul 2020 at 15:10, Justin Obara <obara.justin at gmail.com> wrote:

> 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.  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> 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> 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> 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/5d3c9553/attachment.html>


More information about the fluid-work mailing list