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

We believe that

• improving documentation and reusability
• building in the open and using open source technologies
• making the site user friendly
• ensuring the site meets the U.S. Web Design Standard

Will result in <this outcome>

Will result in other agencies using the open.gsa.gov site as a model.

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.

We will know we are right when

• we get questions from other agencies about the specifics of reusing our site or code
• when we see the influence of our site in other agency development

---

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

We believe that

• introducing an Events section to the site

Will result in increased attendance to GSA open data hackathons and related events.

We will know we are right when

• when we see increased attendance at posted events

---

###Opportunity brief #3 - API developer blog

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)

Reference: 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

We believe that

• providing guides on open data, apis and open source code
• migrating all policy and informational documents relating to open technology within GSA to the site

Will result in increased understanding of GSA open technology.

We will know we are right when

---

###Opportunity brief #6 - 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