Skip to content

Latest commit

 

History

History
59 lines (52 loc) · 3.76 KB

project-process.md

File metadata and controls

59 lines (52 loc) · 3.76 KB

Examples of small processes

Assumptions of government (using Drupal as an example)

  • 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.

Assumptions for vendors

  • 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

Building a reputation system for effective procurement

  • 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

Ongoing Government Committment

  • 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

Timelines

  • 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

Immediate results

  • Upstream fixes to established projects
  • Community review of the code
  • Government learns to write better RFPs
  • Growth of understanding about software development process

Leveraging existing software projects

  • 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