- All code for the project is in an open repository (controlled with git)
- Has a short colophon with list of modules/themes used
- Project description has consise summary workflows for how the project is used from both users and editors
- All patches are stored in a central repository and where relevant contributed upstream so that they are easily trackable
- The client will select a general coding standard - https://www.drupal.org/docs/develop/standards
- Government departments want minimal responsibility for maintaining code developed by contractors
- Maintaining a vibrant ecosystem of open source developers is more important than seeing that each RFP has a maximized ROI.
- It will take many iterations before government can write RFPs that are specific enough and that there is a community of developers who are able to drive enough business to justify ongoing involvement in this ecosystem.
- Individuals and teams working on the project will be made public
- Commits will be made by the individual working on the project
- Company/individual will "own" the open source code produced
- The RFP process will be minimized so that project managers and developers can effectively respond to the outlined expectations
- No more than 10% of the time to complete the project should be required to effectively win the bid
- Teams will be graded based on their ability to deliver. Timelines, budget code quality will be evaluated at the end of the process.
- Acceptance of code into the parent repositories
- Even with everthing being transparent, some technical challenges are more complicated than others. Going over budget is allowed, but will be made public.
- The process will be iterative and be driven by data. Contracts need to be small and predictable enough that it is worth everyone's while to be involved.
- Dozens of contracts are needed with at least ten contractors before you can change the ecosystem inside & outside of government
- Vendors can get "bonus points" for cleaning up unknown problems which weren't known at discovery
- Commit messages will be reviewed againt the code committed
- Keep live repository of project in a public location
- Monitor related issues, patches which are tied to the code used
- Maintaining the software for security & small features
- Government publishes an RFP with ballpark budget and a 3-4 week window for responses
- Everyone gets to anonymously grade the RFP based on how achievable it is
- RFPs need to be SMART (specific, measurable, achievable, realistic and time-bound)
- Vendor questions are discussed in a public issue queue
- Vendors (including individuals) login to central hub and submit bids through an online form with only text submissions
- Small selection team make decisions by reviewing cost, reputation and quality of the response submitted
- Minimum of 5 bids submissions allowed. Extremes (upper & lower bids) are removed.
- It is better to have multiple vendors active at any one time to avoid vendor biases
- Project is implemented & reviewed (possibly by competitor)
- Feedback is collected and added to reputation system
- Upstream fixes to established projects
- Community review of the code
- Government learns to write better RFPs
- Growth of understanding about software development process
- Upgrade modules/plug-ins to the latest release
- Provide UX enhancements to modules/plug-ins
- Do security review of modules/plug-ins
- Performance improvements on modules/plug-ins
- User research on system
- Accessibility enhancments on modules/themes
- Reviewing prior projects