|
CSM now solicits and accepts contributions from external development teams! This is your chance to make your mark on CSM and caCORE as part of the Open Development Initiative. See the CSM Project Page for details about CSM's purpose and function. On this page we define the types of contributions we are looking for and how these contributions will be classified. The specific CSM projects for which we are accepting proposals include:
CSM will consider proposals for any kind of contribution. However, here is a list of contributions we consider most important for our upcoming release:
Watch this space !! In this section we will update what projects and open source contributions have been approved for development in the late Fall release.
First, Take a look at the Wish List posted on this page. Also understand thoroughly the Unit of Contribution descriptions to get a feel for the type of project you would like to work on and your preferred level of participation. Then contact the CSM team to discuss your interest and proposed scope.
Once development is agreed upon, we will work with you to develop a project plan and integration schedule.
During development you will be asked to participate in CSM Status Meetings and CSM Peer Reviews.
Peer Reviews are informal team meetings in which we discuss and review design plans, code, client deliverables, etc.
These meetings will occur regularly as needed throughout the process.
Contact can be made regarding potential contributions at NCICBOpenDevelopment@mail.nih.gov to begin the process. Be sure to include "CSM ODI" in the subject line. We look forward to hearing from you.
Each unit of contribution will be categorized according to the definitions below:
In this category, the project team already knows the scope of the work which they want to be outsourced. They know all the requirements and have completed some level of analysis and design based on those requirements. These requirements may include existing bug fixes, code enhancements or altogether new requirements. The project team has identified the overall architecture as well as the high-level design for the problem. The project team however does not have enough resources to implement and test the changes within a desired timeframe. As the result they can outsource the implementation portion of the change. Following are the responsibilities of the parties involved:
- Develop the problem statement.
- Clearly define the requirements.
- Provide overall architecture and high level design of the solution
- Define the technology stack which is to be used
- Review the implementation provided by the external contributors
- Perform a QA on the solution provided by the contributors before merging it into the main code branch
Contributors:
- If required, construct a low-level design
- Provide well-documented implementation for the solution
- Provide the test plans which were used to test the solution and provide the consequent test results
In this category, the project team identifies a list of requirements and publishes them to the open source community. These requirements may also include existing bug fixes, code enhancements or altogether new requirements. The scope of work is clearly defined and the requirements are published to the external community. The external community’s responsibility is to provide an efficient design for the solution which they plan to implement; keeping it in line with the overall architecture of the project. They need to provide a well-documented implementation of the solution and also provide the test plans. Finally, they need to produce the test results proving the solution functions as designed. Upon receiving this unit of contribution, the project team’s QA team will verify that the solution meets requirements. At the same time, the project team’s development team will make sure that the solution implemented is viable and efficient before merging it with the existing software.
- Develop the problem statement.
- Clearly define the requirements.
- Provide overall architecture
- Define the technology stack which is to be used
- Review the design and implementation provided by the external contributors
- Perform a QA check on the solution provided by the contributors before merging it into the main code branch
- Provide the high level design for the solution.
- Provide a well-documented implementation for the solution
- Provide the test plans which were used to test the solution and provide the consequent test results
In this category, the external contributors are sophisticated users of the project. They have used the project for a while and have discovered certain limitations, found a bug, or suggested useful enhancements for the project. They understand the architecture and working of the project and want to contribute to the project by suggesting changes. In this case the project team analyzes their request, and if it is deemed feasible and attractive, the contributors receive approval to develop the solution. In this category the contributors take ownership throughout the process – from developing initial requirements to implementing the solution .
- Review the problem statement, design and implementation provided by the external contributors
- Define the technology stack which is to be used
- Perform a QA on the solution provided by the contributors before merging it into the main code branch
- Develop the problem statement.
- Clearly define the requirements.
- Provide overall architecture
- Provide the high-level design for the solution
- Provide a well-documented implementation for the solution
- Provide the test plans which were used to test the solution and provide the consequent test results
|
