Table of Contents
PMC Kick-Off meeting
Project goals/constitution:
Is our current project goals/constitution sufficient in the right priority order for the next year.
ref: http://www.sahana.lk/overview
Mifan
+1, with the following change: Point no.2 on the visions statement: Bring together a diverse set of actors from Government, Emergency Management, NGOs, INGOs, spontaneous volunteers and victims themselves in responding effectively to a disaster Basically, we are building a system to help out in this. I guess point no. 2, without the system part is sort of a vision statement that might be more suitable for humanitarian operations, or an NGO.
Model for taking paid / unpaid deployment engagements
How should we give priority to deployment? What is the future model to allow us to scale operations? This is input we should give to the board for the final decision.
Option 2a) Core working bandwidth is allocated for development / QA / releases / Documentation and cannot be repurposed. Development is awarded through fellowship, but QA/Release management are paid employment (i.e. well defined job function and performance measures). These roles remain with LSF. Upgrade release rigor to that of Mozilla Firefox (or close)
Justification: Need to improve rigor of QA, frequency of releases and availability of documentation consistently.
Mifan
IMHO, even though deployments are good as mechanisms of feedback on real world requirements, most development time is spent on these customizations. The downside to this is that core development tasks and the continuous evolution of the project is stalled. On the other hand, having a paid deployment outfit might create problems too, as money is involved on one side, and not on the other. A mutually exclusive model is good for this scenario.
(options need not be mutually exclusive, but sometimes complementary)
Option 2b) Deployment is scaled through a business model by a consortium of companies including possibly a Sahana commercial company. This is again an employment opportunity for Sahana developers.
Justification: Need a separated mechanism to scale deployment proportional to demand
Mifan
At the same time, deployments should be carefully evaluated. I think Sahana is past the stage where it caters to every single request, big or small. We should *NOT* cater to deployments where the client is trying to duplicate efforts of the country in question, the client is working for a greater benefit to himself etc. I guess we have a reputation to protect now, and part of that reputation is strengthened by saying 'NO'.
3) Legal and License rigor
Introducing new processes for accepting contribution. E.g. committer agreement similar to apache committer agreement. Validate acceptable 3rd party licenses that are acceptable for us to use in our code base.
Option 3a) Introduce committer agreement and get all committers to sign. Define matrix of acceptable 3rd party licenses for Sahana.
Justification: Indemnification on code base. Mainly for contributions from commercial companies.
Other Options?
4) Mechanisms for expand community involvement
We need to find ways to better engage the community and their respective skills. To create spaces where they can be more productive in their area of interest, rather than being hesitant to communicate on a generic list.
Option 4a) Create a hierarchically forum with email subscriptions
Justification: Ability to create spaces based on interest, whilst maintaining the benefit of email “push”
5) PMC meeting and decision archival mechanism
Option 5a) New restricted Sahana sourceforge mailing list
Option 5b) Secured Forum section (if we decide on 4a)
5a and 5b are mutually exclusive and lets also get the feedback from the community for input.
Justification: Current mail alias is too basic and no archival takes place of meeting discussions. spam protection is also provided by sourceforge.
Option 5c) WIKI page on Sahana wiki for transparency
Justification: Archival of decisions and summaries of PMC meeting for public consumption