Each community member is an important part of the vision towards the sustainable elimination of poverty.
Muellners Foundation is working on releasing an "*Observation Report and Best Practices Guide*" on the Fineract project. This Foundation is philanthropic, non for profit and privately funded, supporting Fineract’s community development efforts. Muellners Foundation runs a public channel on this project for a closer engagement of the community of participants. There are over 100 members in the channel on Fineract and you or your teams can join them here <https://join.slack.com/share/zt-vwy1scut-X95qd6LFA0ZnFRmuhCeU9w>. Prashant! Would you like to contribute to this report? You can perhaps go through the PMC- Board reports for the last four quarters <https://cwiki.apache.org/confluence/display/FINERACT/2021-07+July+Report>, assess the data on the review mechanism of Pull Requests. PMC reports are public facing, cannot be corrupted once submitted and are supposed to highlight truthful observations on any Apache project as per these guidelines <https://www.apache.org/dev/pmc.html#chair>, so a perfect point to start. I also encourage other individuals, volunteers, student developers, Gsoc mentors, Technology consultants and companies who work with the Fineract project, to participate in this community driven discussion. I have noticed declining community health in the last report and want to create action. I also encourage all the companies, partners consuming Fineract to add their valuable insights on how to make this project governance better. Thanks On Fri, 17 Sep 2021 at 09.04, Prashant Rahulkar <[email protected]> wrote: > Hello Ankit, > > Indeed, its good idea to run the Fineract though PMC, lets plan to > schedule a call > > > > Thanks, > > Prashant Rahulkar. > > > > > > *From:* Muellners ApS [mailto:[email protected]] > *Sent:* Friday, September 17, 2021 1:11 AM > *To:* [email protected] > *Subject:* IMPORTANT: What would you like this community to include as > best practices of maintaining this project? > > > > This is a CALL to discuss governance & maintenance of FINERACT's project > via its Project Management Committee(PMC). Let's discuss how to make > Fineract's PMC inclusive and open. > WHAT IS A PMC? > > A project management committee (PMC) is a committee of the Apache Software > Foundation charged with responsibility and governance > <https://www.apache.org/foundation/governance/pmcs.html> for their top > level project. The PMC is the vehicle through which decision- making power > and responsibility for oversight devolves to developers. > · "Project independence > > While not all ASF projects practice all aspects of the Apache Way in the > same way, there are a number of rules that Apache projects must follow – > things like complying with PMC release voting > <https://www.apache.org/legal/release-policy.html>, legal policy > <https://www.apache.org/legal/>, brand policy > <https://www.apache.org/foundation/marks/>, using mailing lists > <https://www.apache.org/dev/#mail>, etc., which various sites document > <https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different> > . > > One of these invariant rules is that PMCs manage projects independently of > *any* *commercial interests*. The goal is to create an environment in > which *all participants are equal and thus have an equal opportunity* to > contribute to and benefit from our software, regardless of motivation or > financial objectives. There is more discussion of this principle in our > document Project Independence > <https://community.apache.org/projectIndependence.html>." > PMC REQUIRED POLICIES > > Terms in this section as used as per RFC2119 > <https://www.ietf.org/rfc/rfc2119.txt>. The Board expects all PMCs to > understand and comply with these policies. > > Read more here: https://www.apache.org/dev/pmc.html > > > > When you are a newcomer to Apache Software Foundation, guidelines are as > follows: > > > > https://community.apache.org/newcomers/ > > > > Decisions in Apache projects result from: > > - action > - consensus in the community > - (if needed) votes within the community > > We have, over the years, developed a very simple and effective approach to > consensus building and decision making. Projects, and the ASF generally, > make the vast majority of decisions using lazy consensus > <https://community.apache.org/committers/lazyConsensus.html>. If the > “lazy” approach to consensus building seems unsuitable for a particular > decision, we seek to build consensus > <https://community.apache.org/committers/consensusBuilding.html> within > the community. Very occasionally, usually for formal reasons relating to > legal responsibilities, it is necessary to call a vote > <https://community.apache.org/committers/voting.html>. > Casting Your Vote > > The notation used in voting is: > > - +1 Yes, I agree > - 0 I have no strong opinion > - -1 I object on the following grounds > > If you object you must support your objection and provide an alternative > course of action that you are willing and able to implement (where > appropriate). > > With this effort, we are now preparing and working towards best practices > for the project Fineract. > > -- > > Ankit > > Managing Partner > > Muellners ApS, Denmark > > > > Impressum- Muellners® Inc; Copenhagen, Denmark CVR: 41548304; > > New Delhi, India CIN: U72900DL2019PTC344870; Foundation EU CVR:41008407 > > > This mail is governed by Muellners® IT policy. > The information contained in this e-mail and any accompanying documents > may contain information that is confidential or otherwise protected from > disclosure. If you are not the intended recipient of this message, or if > this message has been addressed to you in error, please immediately alert > the sender by reply e-mail and then delete this message, including any > attachments. Any dissemination, distribution or other use of the contents > of this message by anyone other than the intended recipient is strictly > prohibited. All messages sent to and from this e-mail address may be > monitored as permitted by applicable law and regulations to ensure > compliance with our internal policies and to protect our business. E-mails > are not secure and cannot be guaranteed to be error free as they can be > intercepted, amended, lost or destroyed, or contain viruses. You are deemed > to have accepted these risks if you communicate with us by e-mail. >
