Re: Issue tracking

[Tony Atkins]

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  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=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  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  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  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.
>>
&

Re: Issue tracking

[Tony Atkins]

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  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  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  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
>   

Re: Issue tracking

[Justin Obara]

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  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 > <mailto: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

Re: Issue tracking

[Justin Obara]

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  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

Issue tracking

[Justin Obara]

Hi Everyone,

This topic was touched upon in a recent "Enabling Github Issues for Infusion 
project 
”
 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 
, JIRA 
)
That a project/repo is tracked in a JIRA space but doesn’t follow the same 
release and versioning. (e.g. fluid-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