Project hypotheses

Template:

We believe <this capability>

What functionality we will develop to test our hypothesis? By defining a ‘test’ capability of the product or service that we are attempting to build, we identify the functionality and hypothesis we want to test.

Will result in <this outcome>

What is the expected outcome of our experiment? What is the specific result we expect to achieve by building the ‘test’ capability?

We will know we have succeeded when <we see a measurable signal>

What signals will indicate that the capability we have built is effective? What key metrics (qualitative or quantitative) we will measure to provide evidence that our experiment has succeeded and give us enough confidence to move to the next stage.

reference

---

###Opportunity brief #1 - Landing page (homepage)

We believe that...

• there should be a landing page that nicely and professionally lays out data, apis, code, etc.
• gives consideration should be given to graphics and layout, some text here and there but pretty intuitive
• has a hero image, possibly one from a Hackathon, maybe even the GSA DS team
• has personas - curious, developer, data consumer - with appropriate outlets to content
• adheres to style guide, largely to USWDS
• is consistent with previous GSA DS sites
• incorporates DAP scripts, search, feedback form, and signup for listserv

Will result in...

• improved use of the site by the personas and others
• being the model for government and industry open data engagement sites

We will know we are right when...

• all items listed above come to fruition,
• as seen through improved metrics and site feedback

Reference: http://open.gsa.gov/; http://federalist.18f.gov.s3-website-us-east-1.amazonaws.com/site/gsa/open-gsa-redesign/; http://open.nasa.gov; http://open.epa.gov

---

###Opportunity brief #2 - Subpage for Open Data - Sara

We believe that...

• xxx
• xxx

Will result in...

• xxx
• xxx

We will know we are right when...

• xxx
• xxx

Reference: https://anylink(s)here

---

###Opportunity brief #3 - API developer blog - Ryan, think we want a blog for the whole site

We believe that...

• creating an API developer blog with an RSS feed

Will result in...

• improved communication with users of GSA APIs

We will know we are right when...

• users of GSA APIs cheer every time they see us, and offer to buy us pop (or soda)

References: https://github.com/18F/api-standards https://developer.github.com/changes/

---

###Opportunity brief #4 - Subpage for Code

We believe that...

• there should be a landing page for open source code
• it should eloquently lay out GSA's Open Source Software (OSS) policy (including link to OSS repo and pdf), links and narrative around GSA's open source repositories, some narrative around OSS guides for going open source, and where to find more assistance to get to OSS
• there should be DAP scripts installed to allow for tracking transactions with links and documents to measure interest over time

Will result in...

• increased understanding of GSA OSS and increased use of code through GitHub public repos
• in other agencies using our OSS page as a model for display and content

We will know we are right when...

• the number of clicks on our repo link or pdf file
• the number of clicks through to our GitHub repos
• increased inquiries of code that site participants would like to see

Reference: https://github.com/GSA/GSAOpenSourcePolicy

---

###Opportunity brief #5 - Standardize API documentation in industry-standard format

We believe that..

• standardizing the documentation provided for GSA APIs
• using industry-standard API definition (e.g. Swagger, API Blueprint, RAML)
• providing an interactive method of demonstrating API calls and results

Will result in...

• increased engagement with GSA APIs and allow GSA APIs to be discovered an aggregated in online API directories and hubs.

We will know we are right when...

• analytics shows a greater number of page views of documentation
• feedback increases through issues and comments
• GSA APIs are included in more API directories and hubs.

Reference: https://www.govfresh.com/2014/01/next-us-government-api-strategy/

---

###Opportunity brief #7 - Create REST APIs from static data sets

We believe that...

• making REST APIs from static GSA data sets

Will result in increased...

• engagement with GSA APIs.

We will know we are right when..

• analytics of the new APIs shows a greater number of page views of documentation
• feedback increases through issues and comments

---

###Opportunity brief #8 - Create or demonstrate automated tool for creating API from static data set

We believe that..

• providing tools to automate the process of creating APIs from static data sets
• those APIs should follow best practices for design and documentation

*Will result in...

• an increased number of GSA APIs being published that follow best practices.

We will know we are right when...

• GSA static data sets are published as APIs
• the APIs follow best practices for design and documentation

Reference: https://www.govfresh.com/2014/01/next-us-government-api-strategy/

---

###Opportunity brief #9 - Demonstrate Analytics for GSA APIs

We believe that..

• recording the amount of usage for GSA APIs
• providing monitoring and reporting capabilities for APIs

Will result in...

• increased understanding of GSA API usage and load

We will know we are right when...

• GSA APIs are implemented with monitoring and reporting
• API owners report satisfaction with these capabilities

---

###Opportunity brief #10 - Webhooks tbd

We believe that...

• recording the amount of usage for GSA APIs
• providing monitoring and reporting capabilities for APIs

Will result in...

• increased understanding of GSA API usage and load

We will know we are right when...

• GSA APIs are implemented with monitoring and reporting
• API owners report satisfaction with these capabilities

---

###Opportunity brief #11 - Listserv site integration

We believe that..

• the site should have an opportunity for participants to opt into a listserv
• the site listserv should be Google Groups

Will result in...

• increased communication with site users on a regular basis

We will know we are right when...

• a Google Group is created (this could be in test for the Hackathon, just to show us how it works)
• an individual signs up, GSA DS is notified, and a message is sent through listserv that all receive