Thanks Myrle - totally agree we don't want to have copy and paste going on. Jira tickets are canon.
I immediately found that a macro insert works --> https://cwiki.apache.org/confluence/display/FINERACT/Test+page but only for infra tickets. I'll work on figuring this out. Thanks for the suggestion. @jdailey67 On Mon, Mar 4, 2019 at 12:39 AM Myrle Krantz <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > >
