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
   1. Subversion
   2. Bugzilla
   3. Jenkins CI
   4. IRC + mail for coordination
2. Local Environment:
   1. JDK 1.6
   2. Eclipse on local box
      1. Apache Maven
      2. Apache Ant
      3. ANTLR
      4. PHP editing tools
   3. WAMP XAMPP
      1. Apache
      2. MW (trunk)
      3. Simple English db import (current version)
      4. Search Extensions
   4. Tomcat
      1. SOLR
      2. Jenkins CI
3. Testing Environment (Labs)
   1. Virtulization Layer
   2. IP mapping in and out of virtualization adds an extra layre of complexity
4. Production machines for search
   1. Cache access
   2. mediawikiserver
      1. 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. 1. unit test configuration is undocumented.
   2. benchmarking is also tricky.
   3. integration on different os cluster setup need to be tested/
      1. wiki
2. it may not be possible to setup an environment to test it
3. it may not be possible to upgrade without causing catastophic change
4. it may not be possible to