Confirmed users, Bureaucrats and Sysops emeriti
2,088
edits
Firefox OS/Projects/How: Difference between revisions
Jump to navigation
Jump to search
→Designing Projects for Success
No edit summary |
|||
| Line 25: | Line 25: | ||
* '''Do not make “landing” a goal:''' Landing code in Mozilla projects is always harder and takes longer than anyone estimates, even those who've been doing it for many years. These projects should be designed to get as much done as possible *without* landing, and leveraging every possible feature and deployment path to get the code/findings available without having to land it in the core. If we do decided to land the feature in the core, the paid employees can help the project along from that point, doing the unfun stuff like automated unit/integration/performance tests, etc. | * '''Do not make “landing” a goal:''' Landing code in Mozilla projects is always harder and takes longer than anyone estimates, even those who've been doing it for many years. These projects should be designed to get as much done as possible *without* landing, and leveraging every possible feature and deployment path to get the code/findings available without having to land it in the core. If we do decided to land the feature in the core, the paid employees can help the project along from that point, doing the unfun stuff like automated unit/integration/performance tests, etc. | ||
* '''Have clear requirements:''' Your project should clearly define the concept, as well as the skills and technologies are needed. | * '''Have clear requirements:''' Your project should clearly define the concept, as well as the skills and technologies are needed. | ||
* '''Have a clear outcome and deliverables:''' Define a success condition. For researchers, this might an answer to a question, with accompanying research materials, code samples or collected data. For developers, this might be user stories, test cases, specs/mockups, and prototype code. | * '''Have a clear outcome and deliverables:''' Define a success condition. For researchers, this might be an answer to a question, with accompanying research materials, code samples or collected data. For developers, this might be user stories, test cases, specs/mockups, and prototype code. | ||
* '''Regular check-ins:''' Have a weekly or bi-weekly meeting. Regularly scheduled communication avoids projects from heading too far in the wrong direction, or falling too far behind. | * '''Regular check-ins:''' Have a weekly or bi-weekly meeting. Regularly scheduled communication avoids projects from heading too far in the wrong direction, or falling too far behind. | ||
* '''Create Incentives:''' For example, for academic groups ensure the work is being done for credit as part of a formal program. | * '''Create Incentives:''' For example, for academic groups ensure the work is being done for credit as part of a formal program. | ||