tony at raisingthefloor.org
Mon Jul 6 14:16:42 UTC 2020
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.
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
> 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
> 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.
> 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.
> 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
>> 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.
>> 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.
>> 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
>> *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
>> - That a project/repo is tracked in a JIRA space but doesn’t follow
>> the same release and versioning. (e.g. fluid-publish
>> - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work