+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 <a...@fynarfin.io> 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 <lukumuba...@gmail.com> > wrote: > >> +1 >> >> Le ven. 16 sept. 2022 à 15:25, Aleksandar Vidakovic < >> chee...@monkeysintown.com> a écrit : >> >>> +1 >>> >>> On Fri, Sep 16, 2022 at 9:10 AM Bruce <brucetush...@gmail.com> wrote: >>> >>>> +1 >>>> >>>> On Fri, Sep 16, 2022, 9:48 AM Bharath Gowda <bgo...@mifos.org> 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 <jamespdai...@gmail.com> >>>>> 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. >
