You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Isaac Kamga <is...@mifos.org> on 2019/03/04 02:49:03 UTC
Re: FAQ on Wiki, structure of wiki
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 <my...@apache.org> 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 <ja...@gmail.com>
> 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 <my...@apache.org> 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
> >
> >
> >
>
Re: FAQ on Wiki, structure of wiki
Posted by Rahul Goel <ra...@gmail.com>.
Hi James,
Wiki looks great now.
On Tue, Mar 12, 2019 at 10:27 AM Isaac Kamga <is...@mifos.org> wrote:
> Hello James,
>
> You've done a very great job organizing those pages on Confluence.
>
> The entire Wiki looks new and feels refreshing. More grease to your elbows.
>
> Cheers,
> Isaac Kamga.
>
> On Tue, Mar 12, 2019 at 2:25 AM James Dailey <ja...@gmail.com>
> wrote:
>
> > 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 <ja...@gmail.com>
> > 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 <my...@apache.org> 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 <ja...@gmail.com>
> > >> 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 <is...@mifos.org>
> > >> 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 <my...@apache.org>
> > >> 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 <
> > >> jamespdailey@gmail.com>
> > >> > > > 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 <my...@apache.org> 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
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
--
RAHUL GOEL
+91-9873124753
Re: FAQ on Wiki, structure of wiki
Posted by Isaac Kamga <is...@mifos.org>.
Hello James,
You've done a very great job organizing those pages on Confluence.
The entire Wiki looks new and feels refreshing. More grease to your elbows.
Cheers,
Isaac Kamga.
On Tue, Mar 12, 2019 at 2:25 AM James Dailey <ja...@gmail.com> wrote:
> 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 <ja...@gmail.com>
> 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 <my...@apache.org> 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 <ja...@gmail.com>
> >> 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 <is...@mifos.org>
> >> 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 <my...@apache.org>
> >> 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 <
> >> jamespdailey@gmail.com>
> >> > > > 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 <my...@apache.org> 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
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: FAQ on Wiki, structure of wiki
Posted by James Dailey <ja...@gmail.com>.
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 <ja...@gmail.com> 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 <my...@apache.org> 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 <ja...@gmail.com>
>> 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 <is...@mifos.org>
>> 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 <my...@apache.org>
>> 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 <
>> jamespdailey@gmail.com>
>> > > > 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 <my...@apache.org> 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
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: FAQ on Wiki, structure of wiki
Posted by James Dailey <ja...@gmail.com>.
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 <my...@apache.org> 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 <ja...@gmail.com>
> 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 <is...@mifos.org>
> 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 <my...@apache.org> 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 <
> jamespdailey@gmail.com>
> > > > 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 <my...@apache.org> 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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: FAQ on Wiki, structure of wiki
Posted by Myrle Krantz <my...@apache.org>.
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 <ja...@gmail.com> 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 <is...@mifos.org> 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 <my...@apache.org> 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 <ja...@gmail.com>
> > > 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 <my...@apache.org> 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
> > > >
> > > >
> > > >
> > >
> >
>
Re: FAQ on Wiki, structure of wiki
Posted by James Dailey <ja...@gmail.com>.
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 <is...@mifos.org> 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 <my...@apache.org> 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 <ja...@gmail.com>
> > 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 <my...@apache.org> 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
> > >
> > >
> > >
> >
>