User:OrenBochman/Search/Risk Assesssment

=Project Risks=

It is usefull to asses project risk (in development) that could cause the project to fail achieving its goals in a timely basis.

Goals are

 * 1) aproving/paches fixes within a week of thier submission.
 * 2) adressing bug within a month of thier being opened.
 * 3) releasing new version every three months.

1. resources manegment - the project is run by volanteers

 * availability is limited. (working hours)
 * time is limited. (total time available)
 * skill set is limited (ops,dev,labs,production,search,php,robots) etc.
 * interest is limited.

Recommendation

 * 1) Ask wiki project leaders about this.
 * 2) list required resources and be in have contingency taks assignees.
 * 3) use a surgery model (expert mngr + specialist) rather than as orchestra model (expert team).

2. Environment Complexity
the environment is complex and undocumented
 * 1) Web Dev
 * 2) Subversion
 * 3) Bugzilla
 * 4) Jenkins CI
 * 5) IRC + mail for coordination
 * 6) Local Environment:
 * 7) JDK 1.6
 * 8) Eclipse on local box
 * 9) Apache Maven
 * 10) Apache Ant
 * 11) ANTLR
 * 12) PHP editing tools
 * 13) WAMP XAMPP
 * 14) Apache
 * 15) MW (trunk)
 * 16) Simple English db import (current version)
 * 17) Search Extensions
 * 18) Tomcat
 * 19) SOLR
 * 20) Jenkins CI
 * 21) Testing Environment (Labs)
 * 22) Virtulization Layer
 * 23) IP mapping in and out of virtualization adds an extra layre of complexity
 * 24) Production machines for search
 * 25) Cache access
 * 26) mediawikiserver
 * 27) extentions

The environment is (too/uncessseraly) complex to test properly as is.


 * sys-ops know about setting up MW and less about the Dev side.
 * environment is shell based - requiring scripting capabilities.
 * it has OS dependent code which breaks protability.
 * it has cluster specific features which are hard to test
 * poor documentation

OverHead Eats Goodwill

 * 1) it it possible to that overhead unrelated to development will consume goodwill/ available time.
 * 2) it may not be possible to take over the code is it is badly documented.
 * 3) it may be too complex to refacor to SOLR

testing

 * 1) unit test configuration is undocumented.
 * 2) benchmarking is also tricky.
 * 3) integration on different os cluster setup need to be tested/
 * 4) wiki
 * 5) it may not be possible to setup an environment to test it
 * 6) it may not be possible to upgrade without causing catastophic change
 * 7) it may not be possible to