-
Notifications
You must be signed in to change notification settings - Fork 311
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #2075 from 18F/dev
Dev --> master
- Loading branch information
Showing
42 changed files
with
912 additions
and
181 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -133,4 +133,4 @@ RUBY VERSION | |
ruby 2.3.1p112 | ||
|
||
BUNDLED WITH | ||
1.13.5 | ||
1.13.6 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,178 @@ | ||
assigned: | ||
- | ||
text: Home | ||
href: pages/home.md | ||
permalink: / | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
- | ||
text: What we deliver | ||
href: pages/what-we-deliver.md | ||
permalink: /what-we-deliver/ | ||
in_menu: true | ||
in_drawer: true | ||
in_footer: true | ||
children: | ||
- | ||
text: How we work | ||
href: pages/how-we-work.md | ||
permalink: /how-we-work/ | ||
in_menu: true | ||
in_drawer: true | ||
in_footer: false | ||
children: | ||
- | ||
text: Hire 18F | ||
href: pages/hire.md | ||
permalink: /hire/ | ||
in_menu: true | ||
in_drawer: true | ||
in_footer: true | ||
children: | ||
- | ||
text: 'Partnership playbook' | ||
permalink: /hire/partnership-playbook/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
children: | ||
- | ||
text: '1. We build in the open' | ||
permalink: /hire/partnership-playbook/we-build-in-the-open/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: '2. How we work' | ||
permalink: /hire/partnership-playbook/how-we-work/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: '3. Who we work with' | ||
permalink: /hire/partnership-playbook/who-we-work-with/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: '4. Getting started' | ||
permalink: /hire/partnership-playbook/getting-started/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: '5. What to expect' | ||
permalink: /hire/partnership-playbook/what-to-expect/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: Join 18F | ||
href: pages/join.md | ||
permalink: /join/ | ||
in_menu: true | ||
in_drawer: true | ||
in_footer: true | ||
children: | ||
- | ||
text: 'So you want to join 18F?' | ||
permalink: /join/so-you-want-to-join-18f/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
- | ||
text: 'Who we are hiring' | ||
permalink: /join/hiring/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
- | ||
text: 'Who we are hiring' | ||
permalink: /join/hiring/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
- | ||
text: 'How to apply' | ||
permalink: /join/how-to-apply/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
- | ||
text: 'Interview process' | ||
permalink: /join/interview-process/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
children: | ||
- | ||
text: 'Child 1' | ||
permalink: /join/interview-process/child-1/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
- | ||
text: 'Child 2' | ||
permalink: /join/interview-process/child-2/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
- | ||
text: 'Child 2' | ||
permalink: /join/interview-process/child-2/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: false | ||
- | ||
text: Benefits | ||
permalink: /join/benefits/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: 'Government pay grades explained' | ||
permalink: /join/government-pay-grades-explained/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: 'Leave policies' | ||
permalink: /join/leave-policies/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
in_subnav: true | ||
- | ||
text: Blog | ||
href: blog/index.html | ||
permalink: /blog/ | ||
in_menu: true | ||
in_drawer: true | ||
in_footer: true | ||
children: | ||
- | ||
text: Projects | ||
href: _data/projects.yml | ||
permalink: /project/ | ||
in_menu: false | ||
in_drawer: false | ||
in_footer: false | ||
children: | ||
unassigned: [] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
--- | ||
title: Hire 18F | ||
permalink: /hire/ | ||
image: /assets/img/page-feature/hire-us.jpg | ||
lead: Let’s work together to design services that empower your team, better serve the public, and tackle the big problems facing your agency. | ||
--- | ||
|
||
We can work with you to explore and define a variety of problems, and then we can help you build or buy a solution. | ||
|
||
Because of our limited resources, 18F is not able to take on every | ||
project that agencies propose. We select our projects through a | ||
qualification and evaluation process led by our Agency Partnerships | ||
Team. If you and 18F decide that we’re the right fit for a project and | ||
we have the necessary time and resources, we’ll work with you to draft | ||
the necessary documents to begin our partnership. You can read more | ||
about how we work with other agencies in our [Partnership | ||
Playbook](https://pages.18f.gov/partnership-playbook/). | ||
|
||
18F is a cost-recoverable office, which means that we do not receive | ||
appropriated funds from Congress and must charge our partner agencies to | ||
cover our costs. Funding is set up through [Interagency | ||
Agreements](https://pages.18f.gov/iaa-forms/). | ||
|
||
Do you have a project in mind? Let us know: [inquiries18F@gsa.gov](mailto:inquiries18F@gsa.gov) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,16 @@ | ||
--- | ||
permalink: /hire/partnership-playbook/getting-started/ | ||
title: 4. Getting started | ||
--- | ||
|
||
18F ipsum dolor amet user-centered design agency partners test driven development. Agency within government TTS best practices API lean startup model procurement cost-recoverable. Government TTS user-centered design distributed model slack GIF. Cupim GIF government user-centered open transparency 18F. | ||
|
||
Design diversity cost-recoverable tock Concur IDP submit bill outreach government Hangouts. Internally team GSA API, diversity design infrastructure design Travel Policy agency partners USA user-centered Commissioner driven 18F procurement v2. Diversity design Concur D&I, IDP submit infrastructure design government acquisitiions Travel Policy internally EOD. Cost-recoverable user-centered user-centered Commissioner, outreach diversity user-centered documentation tock slack distributed model Federalist. Travel Policy agency API service engagement cost-recoverable GSA API. Agency partners user-centered design slack IDP submit cloud.gov 18F GIF, outreach deprecate engagement GOC All Hands PIF Concur. Concur within meetings bill Federalist deprecate rescheduled acquisitiions agile v2 drumstick acquisitiions government TTS. | ||
|
||
Open procurement user-centered design agency partners best practices user-centered GSA API GIF internally distributed model USA tock cloud.gov government TTS. Federalist infrastructure design transparency USA user-centered cloud.gov analytics agency All Hands PIF outreach. Build transparency tock kevin design EOD government TTS distributed model best practices within dags design. Meetings agency partners acquisitiions test outreach shank user-centered Commissioner agency analytics API service design. Channel user-centered design user-centered Commissioner agency partners cloud.gov lean startup model GSA API. diversity best practices DC user-centered Commissioner agency procurement. | ||
|
||
Team agile slack diversity Travel Policy. Doner agency partners acquisitiions design API service. Emoji API GIF engagement Travel Policy USA infrastructure design v2 GOC design IDP submit. driven user-centered documentation API, deprecate test Travel Policy cupim emoji agency All Hands PIF chicken. Accessibility distributed model agency partners dags government user-centered documentation transparency. | ||
|
||
Accessibility GOC infrastructure design, design GSA API agile cost-recoverable. Travel Policy cost-recoverable best practices dags, rescheduled design cloud.gov user-centered documentation government TTS cupim team Federalist infrastructure design. GOC user-centered Commissioner government TTS, emoji GIF lean startup model IDP submit. Chicken tock diversity acquisitiions rescheduled, https Federalist. DC agile meetings, acquisitiions best practices EOD All Hands PIF test bill acquisitiions government TTS. | ||
|
||
Does your lorem ipsum text long for something a little more open? Give our generator a try… it’s accessible! |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
--- | ||
permalink: /hire/partnership-playbook/how-we-work/ | ||
title: 2. How we work | ||
--- | ||
|
||
It’s important for us to build digital services that solve the needs of users and are enjoyable to use. By the time you’re designing a solution, you should have a solid understanding of the users you’re building for and the problems you’re trying to solve. Though the needs of agency stakeholders are important, the satisfaction of citizens or other end-users are the primary way we measure success. | ||
|
||
You can see more information about the methods our design team uses at [this site](https://methods.18f.gov/) and read more on our blog about [user interview best practices](https://18f.gsa.gov/2016/02/09/tips-for-capturing-the-best-data-from-user-interviews/). | ||
|
||
*Tip: In user-centered design, we conduct interviews with users to understand their needs and how they experience the status quo. Your agency can start by speaking with call center or customer service representatives to sketch out personas — or composite representative descriptions — of types of customers and what their needs and behaviors are.* | ||
|
||
###What does this mean for you? | ||
Together, we will prioritize your users and their problems. Most agencies serve several different user groups. Who are your most important users, and what problems are you solving for them? | ||
|
||
[User stories](https://en.wikipedia.org/wiki/User_story) are the primary way of expressing software functionality without specifying how it's technically implemented. As the agency representative, your product owner will write and prioritize user stories with input and research from the team. Each sprint, the team chooses the top priority user stories, then builds functionality and tests it with actual users to measure whether the feature meets its intended outcome. | ||
|
||
Our joint product team will understand if we’re building the right thing by continuously getting our work in front of users (ideally, every few weeks or sprint). We will rely on your agency to recruit users for us to speak with. For a medium-sized project, we will likely want about six new users every two to four weeks. | ||
|
||
###How do you know if you’re ready to work in a user-driven way? | ||
|
||
>- Do you have a first draft of who you think the main users are? Have you created [personas](https://en.wikipedia.org/wiki/Persona_%28user_experience%29)? | ||
- When is the last time you spoke to your users? Family and friends don’t count. | ||
- Which users are the priority? (They all can’t be the priority.) | ||
- Can you recruit three users for us to speak with before our first workshop? | ||
- Will you allow the project solution to change as you learn from users? |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,17 @@ | ||
--- | ||
title: Partnership Playbook | ||
permalink: /hire/partnership-playbook/ | ||
lead: Let’s work together to design services that empower your team, better serve the public, and tackle the big problems facing your agency. | ||
--- | ||
|
||
This guide will help you, as an agency, understand what it’s like to work with the 18F team. You'll learn what to expect and get a sense of the challenges you may face when working with a digital service team, which will likely be a significantly different experience than working with a contractor. Many of the principles below build on specific plays in the [U.S. Digital Services Playbook](https://playbook.cio.gov), which some 18F staffers assisted in authoring. | ||
|
||
The principles we use in working together are: | ||
|
||
>1. [We build in the open.]({{ site.baseurl }}/hire/partnership-playbook/we-build-in-the-open/) | ||
2. [How we work.]({{ site.baseurl }}/hire/partnership-playbook/how-we-work/) | ||
3. [Who we work with.]({{ site.baseurl }}/hire/partnership-playbook/who-we-work-with/) | ||
4. [Getting started.]({{ site.baseurl }}/hire/partnership-playbook/getting-started/) | ||
5. [What to expect.]({{ site.baseurl }}/hire/partnership-playbook/what-to-expect/) | ||
|
||
We’ll explain what each principle will mean to you as our partner. We also provide a set of prompting questions in the “How do you know if you’re ready” sections, which you can use with stakeholders to assess potential conflict points that may need to be resolved before we partner. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
--- | ||
permalink: /hire/partnership-playbook/we-build-in-the-open/ | ||
title: 1. We build in the open | ||
--- | ||
|
||
18F works in the open [from day one]({{ site.baseurl }}/2014/07/31/working-in-public-from-day-1/) of a project, and our resulting code is dedicated fully to the public domain. In addition, any contracts 18F enters into where others will develop software on 18F's behalf ensure that all results are dedicated to the public domain. For our international colleagues, 18F also permanently waives all copyright and related rights worldwide to code created by 18F or its contractors. | ||
|
||
We operate in this way for three reasons: | ||
|
||
1. **Operating in the open streamlines communication.** GitHub issues can be used without concern about access permissions and account creation. Access to the project is available regardless of VPN or location, without additional verification requirements. [Open source](https://github.com/18F/open-source-policy/blob/master/policy.md) repositories are an easy and accessible location to find source code when pulling in additional experts to check out a problem. | ||
2. **Transparency builds trust with the public**, since everyone’s work is accessible to others. Transparency also builds trust within the government, since we can freely pull and cite methods and ideas from existing projects without worrying about possibly revealing something inappropriate. | ||
3. **Working in the open helps to encourage good documentation and coding practices.** Everyone is aware of and following processes for open information from day one. There is no just-before-launch, last-minute review of everything. All code and documentation is reviewed as it’s developed. | ||
|
||
###What does this mean for you? | ||
Your tools will be developed in public view. While our open source policy explicitly covers software, 18F also publishes much of its designs, product discussions, and other artifacts in the open as a matter of policy, principle, and working preference. This fosters a working environment that is more conducive to outside feedback and contributions, and increases operational awareness of the work across our project teams and those of our partners. In one example, we and a partner office at EPA successfully opened a project's [internal task management tool to public view]({{ site.baseurl }}/2015/12/07/what-exactly-do-we-even-do-all-day/). | ||
|
||
The public will be able to examine the code, point out issues, and suggest edits (all edits must be accepted by authorized personnel on the 18F or partner agency team). While they aren’t guaranteed, we celebrate public contributions to our code. Interest groups may take note of the developing project once it is publicized. | ||
|
||
Additionally, we will write about the work (or the process used to create the work) in public blog posts, case studies, or other means (social media, etc). Communicating openly is a critical process that we've put in place to stop the government from repeating the same mistakes. Not sharing solutions and best practices — both between different teams inside the government and between the government and private sector — has led to financial waste and damage to the public. We need the ability to communicate solutions as fast as we find them, and the most effective way to do that is to work in the open. | ||
|
||
|
||
###How do you know if you’re ready to work in the open? | ||
As you consider working with 18F, reflect on the following questions with your stakeholders. You may not be able to answer "yes" to each one, but they can help serve as indicators of potential conflict points that may need to be resolved before we partner. If any of these look like red flags to you, please raise them right away with your 18F point of contact and we'll work together to address them. | ||
|
||
>- Are you already working in the open or using open source products? | ||
- Have you and your IT department discussed developing your project with open source? | ||
- Has your agency developed other projects using open source code? | ||
- Have you taken a look at 18F’s GitHub repositories to become familiar with how open source projects look? ([Example 1](https://github.com/18F/openFEC), [Example 2](https://github.com/18F/federalist), [Example 3](https://github.com/18F/calc)) | ||
- Have you talked to your communications team about how you plan to announce and promote the project? |
Oops, something went wrong.