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
> > >
> > >
> > >
> >
>
