If you're going to be carrying over information from Jira, you should look into whether its possible to use the jira integration in confluence so that it can be done automatically. Then create shared filters on release numbers and you have "one source of truth" rather than spreading information between two systems and leaving everyone to wonder which is canonical.
I don't know though if this will work without Infra involvement. You may need to ask. Best Regards, Myrle On Mon, Mar 4, 2019 at 4:36 AM James Dailey <[email protected]> wrote: > Hi Isaac -- Thanks for the input. I'd also like to have community members > be able to more easily understand the needs and the priorities. Some of > that, I hope, can be incorporated into the FAQ. > > At the risk of expanding this topic just a tad, there should be a norm for > a newbie to: > * Consult the main page, consult the FAQ, high level pages on wiki > * Join the listserv > * Browse some tickets > * Set up dev environment (if coding) or demo environment (if documentation > or UI) > * Dig further into wiki > * Ask questions about specific tasks or code on the list > > I take Myrle's suggestion as to not have a roadmap that makes the project > look bad when we don't meet specific dates and capabilities. We want an > accurate reflection of the level of work going on and the actual > priorities. The PMC report has had good information about what is actually > going on. > > Looking at just roadmaps, we want to focus, I think, on three levels: > > *Level A)* high level product roadmap - laying out broad areas of > improvement or enhancement to communicate "what would be useful?" ; > in my mind, the high level community roadmap should be something that > is able to be referenced and not changed much over an 18 month period > this should not have dates, more about priorities > > *Level B)* roadmap of specific enhancements that stand in for the lack of > "Epics" in apache jira set up. This may be too labor intensive so only > should be done for specific higher profile things. ("Epics" are high > level, can be related to a product need, and reference multiple jira > tickets) > > *Level C)* a bit more controversial perhaps, but one thing I know about > open source projects is that they (we) should also have the "anti-roadmap", > the areas that fineract does NOT intend to do. Why? This gives space for > the commercial users of the code to come up with add-ons and wrappers that > then create the virtuous cycle of contribution. That anti-roadmap should be > fairly broadly stated. e.g. we won't develop deployment tools or training > materials.... we leave that to other players in market > > So, I think for now, I'd like to mark "To-be-deprecated" on pages that are > not active, haven't been updated in over 12 months. If they are actually > active and relevant, then the person involved in maintaining that page can > easily remove that term, and if not, then after a reasonable period of time > - say 30 days - we put those pages into full Deprecated status. > > Given the discussion thus far and using our lazy consensus approach, I'm > going to move forward on the restructuring first. > > Thanks, > jdailey > > > On Sun, Mar 3, 2019 at 6:49 PM Isaac Kamga <[email protected]> wrote: > > > Hello James, > > > > Thanks for the immense efforts you're putting into making the wiki more > > visible and supple. > > > > Besides being open source best practice, I think the community roadmap > > should be left there given it provides clarity to volunteers, puts open > > issues in context and doesn't coerce anyone with tight deadlines. > > > > Cheers, > > Isaac Kamga. > > > > On Thu, Feb 28, 2019 at 2:56 PM Myrle Krantz <[email protected]> wrote: > > > > > Hey James, > > > > > > The FAQ looks good. Really good. > > > > > > I like your proposed restructuring of the Wiki too. I would suggest > two > > > changes: > > > * Leave a space for discussing/document architecture/design decisions. > > > * Remove the roadmap. We are mostly volunteers. We shouldn't be > making > > > promises about future development. We'll only be making liars out of > > > ourselves. And besides, this area is mostly duplication of Jira > anyways, > > > so creating an area like this creates unnecessary data duplication > > > efforts. Or it means the task data are being captured solely in > > > confluence, which just is less good than jira for that purpose. > > > > > > But since I won't have time to help you on it, you can take my opinions > > or > > > leave them. > > > > > > Best Regards, > > > Myrle > > > > > > On Thu, Feb 28, 2019 at 12:51 AM James Dailey <[email protected]> > > > wrote: > > > > > > > Devs - > > > > > > > > I have noted a number of emails from people with basic questions > about > > > the > > > > project and have tried to collate those into a FAQ. Please see my > > > changes > > > > to https://cwiki.apache.org/confluence/display/FINERACT/FAQ. If you > > > > object, either respond to this email or make comments on the page > > itself. > > > > > > > > As previously communicated I am also thinking we need to change the > > > > structure of the navigation for the project - the left side "Page > Tree" > > > at > > > > https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Home ; > > > > While it is now familiar to many of us, to a new person I think it > > > remains > > > > very confusing. > > > > > > > > @Myrle Krantz <[email protected]> please suggest if this is > something > > > > you'd like to collaborate on... > > > > The structure I think should follow this with other content below > these > > > > two top levels: > > > > > > > > 1. Getting Involved & Community Norms > > > > 1. Getting Started > > > > 2. PMC reports > > > > 3. Contributors & Committers > > > > 4. How To Articles > > > > 2. Fineract > > > > 1. Roadmap > > > > 2. Releases > > > > 3. Getting started (pull out specifics to Fineract1.x) > > > > 4. Functional specs > > > > 5. User Zones > > > > 3. Fineract CN > > > > 1. Roadmap > > > > 2. Releases > > > > 3. Getting started (pull out specifics to Fineract-CN) > > > > 4. Functional specs > > > > 5. User Zones > > > > 4. Blog & Outbound Communications > > > > 1. Presentations Given > > > > 2. Speech text > > > > 5. FAQ > > > > > > > > > > > > > > > > > >
