+1 On Mon, Oct 10, 2022, 8:27 PM James Dailey <[email protected]> wrote:
> +1 (binding) > > We have three binding votes (PMC members) and support from active > community members. Thank you. > We have left this open for community input for over two weeks. > So, to re-enforce our process: this is closed and we proceed to > implementation of this set of policies and actions. > > I shall move this to a wiki page with the clarifications that Avik > offered. > > > > > > > > On Mon, Sep 19, 2022 at 7:39 AM Avik Ganguly <[email protected]> wrote: > >> Hi James, Devs, >> >> +1 >> >> There should be some bulk interfaces or JIRA APIs to drive via pipelines >> / actions to make it simpler to execute as many other communities do. >> >>> >>> 1. *At each release cycle*, a further list of tickets will be sorted >>> based on which versions are affected. Versions older than THREE ago will >>> be >>> considered "non-active". >>> >>> To clarify for other readers, the bold part is applicable to minor/major >> release cycles and not for patch / hotfix releases. >> >> With best regards, >> Avik. >> >> On Fri, Sep 16, 2022 at 8:11 PM Chantilly Muyaya <[email protected]> >> wrote: >> >>> +1 >>> >>> Le ven. 16 sept. 2022 à 15:25, Aleksandar Vidakovic < >>> [email protected]> a écrit : >>> >>>> +1 >>>> >>>> On Fri, Sep 16, 2022 at 9:10 AM Bruce <[email protected]> wrote: >>>> >>>>> +1 >>>>> >>>>> On Fri, Sep 16, 2022, 9:48 AM Bharath Gowda <[email protected]> wrote: >>>>> >>>>>> +1 for the suggested approach. >>>>>> >>>>>> Regards, >>>>>> Bharath >>>>>> Lead Implementation Analyst | Mifos Initiative >>>>>> Skype: live:cbharath4| Mobile: +91.7019635592 >>>>>> http://mifos.org <http://facebook.com/mifos> >>>>>> <http://www.twitter.com/mifos> >>>>>> >>>>>> >>>>>> On Fri, Sep 16, 2022 at 10:42 AM James Dailey <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Devs - >>>>>>> >>>>>>> We currently have a lot of open and stale tickets, with the average >>>>>>> days open being over 1000 days (over the past two years on any >>>>>>> given day >>>>>>> <https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=project-12319420&periodName=monthly&daysprevious=730&selectedProjectId=12319420&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Aaverageage-report&atl_token=A5KQ-2QAV-T4JA-FDED_27535cfecdbfc0e03095e17815dc0d6cf7af61a1_lin&Next=Next>). >>>>>>> A group of us met on Zoom to discuss and we propose the below approach. >>>>>>> See details I shared on wiki >>>>>>> <https://cwiki.apache.org/confluence/display/FINERACT/Jira+Clean+Up>, >>>>>>> including recording. If there is no objection we will begin this >>>>>>> clean up in the next week or so. >>>>>>> >>>>>>> 1. *Archiving*: A list of tickets older than 26 months will be >>>>>>> generated and published to the list. The message will be to please >>>>>>> review. >>>>>>> >>>>>>> 1. IF any reviewer finds that the ticket should NOT be >>>>>>> archived, then that person should indicate by putting a comment >>>>>>> on the >>>>>>> ticket indicating their interest in working on the ticket further >>>>>>> (validating issue, specifying more, testing, fixing), ideally >>>>>>> with the >>>>>>> person self-assigning it to themselves. >>>>>>> 2. Otherwise within a set period of time (five days), all >>>>>>> those tickets will be "Closed" with a tag added "Cleanup22", and >>>>>>> a status >>>>>>> of "Auto Closed" >>>>>>> 2. Those closed tickets will be archived, and available for >>>>>>> further review and may be re-opened, with cause. >>>>>>> 3. *At each release cycle*, a further list of tickets will be >>>>>>> sorted based on which versions are affected. Versions older than >>>>>>> THREE ago >>>>>>> will be considered "non-active". >>>>>>> 1. NB: This is a formalization of a practice we have, which >>>>>>> is to deprecate older versions and encourage our users to upgrade >>>>>>> to the >>>>>>> most recent stable release. As we are on version 1.8 now, any >>>>>>> issue >>>>>>> affecting 1.4 or older would be "unsupported". As soon as we >>>>>>> release 1.9, >>>>>>> version 1.5 becomes "unsupported". >>>>>>> 2. This led to a further discussion of release strategy - >>>>>>> which I will start as a different thread. The main point being, >>>>>>> if a >>>>>>> release is no longer a supported release, then those tickets are >>>>>>> to be >>>>>>> archived. >>>>>>> 4. *Issue Reporting and Cleanliness: *We will require the >>>>>>> tickets to include "Version affected" and "Component" to be filled >>>>>>> out. This allows the sorting above and provides for the ability >>>>>>> to trace the origin of the issue. We also seek to have better ticket >>>>>>> reporting, meaning a clear set of criteria for "Bug" vs >>>>>>> "Configuration/Documentation" vs "New Feature". >>>>>>> 5. We will hold a regular - monthly - issue triage meeting to >>>>>>> coordinate on tickets. >>>>>>> 6. We noted that many of the issues on the list and some of >>>>>>> the Jira tickets are related to configuration and setup and suggest >>>>>>> better >>>>>>> knowledge base management. We are interested in people taking an >>>>>>> active >>>>>>> role in that. >>>>>>> 7. *Release Cycles: *We noted that we have gotten a number of >>>>>>> major improvements such that version 1.8 is very different from 1.5 >>>>>>> (less >>>>>>> than two years ago). A new topic is thus to move to a Major release >>>>>>> cycle >>>>>>> Version 2.0, and to consider a Long-Term-Support version of the >>>>>>> Fineract1.x >>>>>>> . I can kick that off on a new thread as well. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> Disclaimer: >> >> Privileged & confidential information is contained in this message >> (including all attachments). If you are not an intended recipient of this >> message, please destroy this message immediately and kindly notify >> the sender by reply e-mail. Any unauthorised use or dissemination of this >> message in any manner whatsoever, in whole or in part, is strictly >> prohibited. This e-mail, including all attachments hereto, (i) is for >> discussion purposes only and shall not be deemed or construed to be a >> professional opinion unless expressly stated otherwise, and (ii) is not >> intended, written or sent to be used, and cannot and shall not be used, for >> any unlawful purpose. This communication, including any attachments, may >> not be free of viruses, interceptions or interference, and may not be >> compatible with your systems. You should carry out your own virus checks >> before opening any attachment to this e-mail. The sender of this e-mail and >> *Fynarfin Tech Private Limited* shall not be liable for any damage that >> you may sustain as a result of viruses, incompleteness of this message, a >> delay in receipt of this message or computer problems experienced. >> >
