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.jus...@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.jus...@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.jus...@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 > > > > >
_______________________________________________________ fluid-work mailing list - fluid-work@lists.idrc.ocad.ca To unsubscribe, change settings or access archives, see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
