Hi All - I've made a bunch of changes to the navigation and structure of the wiki.
I'd like to know if I should deprecate additional pages. For example, are we still relying on the specifications under https://cwiki.apache.org/confluence/display/FINERACT/Apache+Fineract+1.0+Functional+Specifications By Deprecating them, we would indicate that they no longer are authoritative. So, I think the question - are these pages still accurate? James Dailey skype: jdailey On Mon, Mar 4, 2019 at 10:25 AM James Dailey <[email protected]> wrote: > 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 >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > >> >
