PMC Kick-Off meeting

Project goals/constitution:

Is our current project goals/constitution sufficient in the right priority order for the next year.



+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

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.


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


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

QR Code
QR Code board:pmc (generated for current page)