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.jus...@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 <t...@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.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
