This guide builds upon our getting started guide in order to help 18F's Micro-purchase customers solicit small, measurable contributions to open source software projects.
18F's Micro-purchase platform enables government employees to solicit small, measurable contributions to open source software projects through the use of reverse-auctions. To list auctions for you, 18F's Micro-purchase team will need the following information:
This document provides general guidance to help you locate the information listed above. 18F's Micro-purchase team will take it from there, tailoring one or more auctions to fit your needs.
As we get closer to publishing your auction(s), our team will ask you for the date and time when the auction(s) should start, as well as who within your office or agency will be the primary point of contact for vendors during the bidding and delivery periods. We'll also need to know who within your office or agency will be able to accept the content or code that's ultimately submitted by the vendor.
This is pretty straightforward: in order to solicit contributions, you're going to first need to either create or identify an open source project. All we need is a link to an open source project(s) on GitHub. If you've somehow gotten this far without doing that, our team is happy to help!
Next, we'll need a summary of the changes that you'd like to see made. In keeping with the best practices of agile development, our team prefers that these changes come in the form of user stories. (Those stories should also be informed by user research and tie back to product- or feature-level hypotheses.)
After you've written user stories, be sure to prioritize and socialize them across your team. This ensures that everyone knows the details of what's being requested, and when to expect the delivered work so that they can merge it into the codebase.
Finally, with regard to the design of 18F's Micro-purchase Platform, specifically: Our team requires a "summary " for each auction that's exactly 250 characters or fewer. Note that this is in addition to the user stories identified above. Summaries appear in the "cards " associated with each auction, like so:
Auctions on the Micro-purchase platform default to $3,500 because this is the single-purchase limit for GSA's purchase cards. That said, bidding can start anywhere below this amount and should roughly correspond to the amount of work you think it'll take to complete the changes you've requested.
The next thing you'll want to do is to further break your user stories into scenarios, and create objective acceptance criteria associated with each scenario.
This is an important step. The clarity and objectivity your auction's acceptance criteria ultimately helps reduce the cost you will incur because it allows vendors to more clearly determine whether or not they will be able to deliver. Moreover, while they're delivering, vendors should be able to refer back to your acceptance criteria to know whether or not they are on the right track or whether they'll need to adjust course.
Good acceptance criteria should strike a balance between specifying your functional needs — that is, specifying what the software should do differently after the auction has ended — with specifying how vendors might achieve that change. In general, the "how" should be left to the vendor. If there is a suggested implementation, this should be noted separately from the acceptance criteria.
To ensure objective acceptance criteria you might:
Specifying the skills required for a particular auction will help vendors self qualify. If your code is written in Python, for example, you should specify Python as a skill so that developers with Python experience can more easily find and address your request. You can see a list of the skills requested by past auctions by visiting our insights page.
Open source software teams often use GitHub's issues feature to track bugs, note deficiencies, and make feature requests. Please let us know if there are any GitHub issues already associated with the changes you're requesting. If not, please do us a favor and make an issue for each change you'd like to request. That way we can mark those issues as resolved once your auctions are delivered.
We prefer that customers use their office or agency's purchase card (p-card) to pay vendors for their contributions. That said, if your team is already working with 18F on a project, contact your project lead. We may be able to use 18F's p-card and just bill the total auction expense (final auction, plus our platform fee) to our existing agreement (IAA) with your agency.
The typical Micro-purchase auction takes one or two days, and vendors are usually asked to deliver within five business days of an auction's closing. While we've had cases where vendors have failed to deliver, our success rate for first-run auctions is 80%.
Be prepared for the possibility that a requirement might not be successfully delivered after the first try, and that you may need to re-run an auction. Also be prepared to work through unanticipated issues during the delivery period in order to complete the auction.
We learn more from each auction and work hard to incorporate these learnings into subsequent auctions. We are trying to hit the sweet spot where the vendors feel empowered and the customer gets what they want, and our goal is to do this 100% of the time. Remember to have patience and to be agile. :)
As outlined on our policies page, auctions on our platform go through a general workflow, from unpublished to published ("coming soon"), and from open to closed. During our initial chats, our team will draft auctions in an "unpublished " state. As soon as we we have all required information, including budget approvals, and a start date, we will publish your auction in the "coming soon " state. Auctions can be unpublished only while they've yet to receive a bid. Said differently, we cannot unpublish an auction once it has received a bid.