├── README.md ├── CONTRIBUTING.md ├── LICENSE.md ├── ISSUE_TEMPLATE └── INCIDENT_RESPONSE.md ├── CODE_OF_CONDUCT.md ├── Poliy └── OpenSource.md └── Practice └── OpenSourcePractice.md /README.md: -------------------------------------------------------------------------------- 1 | # .github 2 | default-community-health 3 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## Welcome! 2 | 3 | We're so glad you're thinking about contributing to an 18F open source project! 4 | If you're unsure about anything, just ask -- or submit the issue or pull request 5 | anyway. The worst that can happen is you'll be politely asked to change 6 | something. We love all friendly contributions. 7 | 8 | We want to ensure a welcoming environment for all of our projects. Our staff 9 | follow the [18F Code of 10 | Conduct](https://github.com/18F/code-of-conduct/blob/master/code-of-conduct.md) 11 | and all contributors should do the same. 12 | 13 | We encourage you to read this project's CONTRIBUTING policy (you are here), its 14 | [LICENSE](LICENSE.md), and its [README](README.md). 15 | 16 | If you have any questions or want to read more, check out the [18F Open Source 17 | Policy GitHub repository]( https://github.com/18f/open-source-policy), or just 18 | [shoot us an email](mailto:18f@gsa.gov). 19 | 20 | ## Public domain 21 | 22 | This project is in the public domain within the United States, and copyright and 23 | related rights in the work worldwide are waived through the [CC0 1.0 Universal 24 | public domain dedication](https://creativecommons.org/publicdomain/zero/1.0/). 25 | 26 | All contributions to this project will be released under the CC0 27 | dedication. By submitting a pull request, you are agreeing to comply 28 | with this waiver of copyright interest. 29 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | # License 2 | 3 | As a work of the [United States government](https://www.usa.gov/), this project is in the public domain within the United States of America. 4 | 5 | Additionally, we waive copyright and related rights in the work worldwide through the CC0 1.0 Universal public domain dedication. 6 | 7 | ## CC0 1.0 Universal Summary 8 | 9 | This is a human-readable summary of the [Legal Code (read the full text)](https://creativecommons.org/publicdomain/zero/1.0/legalcode). 10 | 11 | ### No Copyright 12 | 13 | The person who associated a work with this deed has dedicated the work to the public domain by waiving all of their rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. 14 | 15 | You can copy, modify, distribute, and perform the work, even for commercial purposes, all without asking permission. 16 | 17 | ### Other Information 18 | 19 | In no way are the patent or trademark rights of any person affected by CC0, nor are the rights that other persons may have in the work or in how the work is used, such as publicity or privacy rights. 20 | 21 | Unless expressly stated otherwise, the person who associated a work with this deed makes no warranties about the work, and disclaims liability for all uses of the work, to the fullest extent permitted by applicable law. When using or citing the work, you should not imply endorsement by the author or the affirmer. 22 | -------------------------------------------------------------------------------- /ISSUE_TEMPLATE/INCIDENT_RESPONSE.md: -------------------------------------------------------------------------------- 1 | ### Important Information 2 | - Do not not delete any potential evidence (deleting GitHub repositories) 3 | - Do not modifiy any potential evidence (stopping or allowing an app to be terminated) 4 | - If _classified information_ is part of the incident, do not attach the information to your report. Wait for instructions from GSA Incident (IR) team. 5 | - If email is unavailable, [contact GSA IR team another way](https://handbook.18f.gov/gsa-internal-tools/#it-service-desk) 6 | - Keep as much of the conversation in the [#incident-response](https://gsa-tts.slack.com/messages/incident-response) Slack channel. 7 | 8 | ### Actions Performed to date 9 | _Reporting phishing emails_ 10 | - [ ] Mark it as spam 11 | - [ ] Follow the [“To report a suspicious email”](https://insite.gsa.gov/topics/information-technology/do-it-yourself-self-help/google-g-suite-apps/email-with-gmail/phishing-emails-and-scams#Report%20suspicious%20emails) directions on the [Phishing Emails and Scams InSite page](https://insite.gsa.gov/topics/information-technology/do-it-yourself-self-help/google-g-suite-apps/email-with-gmail/phishing-emails-and-scams#Report%20suspicious%20emails). 12 | - [ ] Use Confense tool as instructed 13 | 14 | _Reporting phishing incidents_ 15 | (If you also clicked on a link in a phishing email, follow these steps to report to GSA IR:) 16 | - [ ] Follow stpes from _Reporting phishing emails_ 17 | - [ ] Send an email to itservicedesk@gsa.gov and devops@gsa.gov 18 | - [ ] Included _Security Incident_ in the subject line of email 19 | - [ ] Included brief description of the incident 20 | - [ ] Report the phishing email in the [#incident-response](https://gsa-tts.slack.com/messages/incident-response) Slack channel. 21 | 22 | _Initial contact_ 23 | - [ ] Incident has been notified per [IR Handbook](https://handbook.18f.gov/security-incidents/) 24 | - [ ] Sent email to itservicedesk@gsa.gov, gsa-ir@gsa.gov, and devops@gsa.gov within 1 hour of incident 25 | - [ ] Included _Security Incident_ in the subject line of email 26 | - [ ] Included brief description of the incident (Ex. security token committed to GitHub repo) 27 | - [ ] Included URL (if any) 28 | - [ ] Repos (if any) 29 | - [ ] Related GitHub issue (if applicable) 30 | 31 | _Creating an Issue_ 32 | - [ ] Check to make sure data is not sensitive 33 | - [ ] If no sensitive data, open a [GitHub Issue in the security-incidents repository] (https://github.com/18F/security-incidents/issues/new) 34 | - [ ] If sensitive data, createa a Google Drive folder 35 | - [ ] If sensitive data, share Google Drive Folder w/ Devops@gsa.gov and gsa-ir@gsa.gov *ONLY* 36 | - [ ] If sensitive data, make sure using GSA Google Drive folder in the "My Drive" and not within a pre-existing folder 37 | - [ ] If sensitive data, share link to Google Drive Folder via Slack, GitHub or via email 38 | 39 | _Additional Steps_ 40 | -[ ] [cloud.gov](https://cloud.gov/) specific [checklist](https://cloud.gov/docs/ops/security-ir-checklist/) 41 | -[ ] If the incident is related to cloud.gov, please ensure they CC the cloud.gov team (cloud-gov-support@gsa.gov) 42 | 43 | ### What to Expect Next 44 | Following notification to GSA, the Incident Response team will contact you requesting more information. 45 | 46 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # The Technology Transformation Service Code of Conduct 2 | 3 | **Table of Contents** 4 | 5 | [Introduction](#introduction) 6 | 7 | [What We Strive For](#what-we-strive-for) 8 | 9 | [Unacceptable Behavior](#unacceptable-behavior) 10 | 11 | [Reporting](#reporting-violations) 12 | 13 | [Credits](#credits) 14 | 15 | [Version](#version) 16 | 17 | ## Introduction 18 | 19 | TTS is committed to building a safe, welcoming, harassment-free culture for everyone. We do not merely want a work environment that is free from hostility; we want one that is actively welcoming and inclusive. We want our team and our workplace culture to reflect and celebrate the diversity of the communities we serve. 20 | 21 | This Code of Conduct summarizes federal anti-harassment law and General Services Administration policy. We intend the plain-language approach to promote a culture of inclusion and respect. 22 | 23 | We expect everyone on the TTS team to exhibit these behaviors and abide by applicable federal laws and GSA policies. In addition, we expect everyone within TTS spaces to exhibit these behaviors and refrain from behavior prohibited by anti-harassment laws and GSA policies on harassment. These spaces include: 24 | 25 | - TTS's physical offices, 26 | - TTS events and meetings, 27 | - All of our online forums and virtual collaboration tools, including: 28 | - Office chat rooms, like Slack 29 | - Mailing lists and email 30 | - Code repositories, like GitHub 31 | 32 | ## What We Strive For 33 | 34 | We strive to create a welcoming and inclusive culture that empowers people to provide outstanding public service. That kind of atmosphere requires an open exchange of ideas balanced by thoughtful guidelines. If we have only openness, colleagues who are on the receiving end of thoughtless or intentionally hurtful comments and behavior may reasonably withdraw. If we have overly intrusive guidelines, people may feel unwelcome. 35 | 36 | It would be impossible to list everything staff can do to create a more welcoming space, and we know this team will find ways to include their colleagues that we haven't even thought of. But when in doubt, we encourage you to look to these principles for guidance: 37 | 38 | - Practice empathy and humility. 39 | - Assume competence in your colleagues, clients and the public. 40 | - Assume that everyone we work with is doing their best work for the public. 41 | - Listen carefully and actively. 42 | - Ask questions, and seek to understand your partners' context. 43 | - Encourage other people to listen as much as they speak. 44 | - Treat other people's identities and cultures with respect. Make an effort to say people's names correctly and refer to them by their chosen pronouns. 45 | 46 | ## Unacceptable Behavior 47 | 48 | To help colleagues understand the kinds of behaviors that are illegal or run counter to the culture we seek to foster, we've listed below actions that violate federal law and GSA policy. We've also included steps to take if you encounter behavior that runs contrary to this policy. 49 | 50 | ### Sexual and Non-Sexual Harassment 51 | The [GSA Policy](https://www.gsa.gov/portal/directive/d0/content/512516) Statement on Sexual and Non-Sexual Harassment forbids: 52 | 53 | - Sexual and non-sexual harassment and misconduct, as defined in [GSA Order ADM 2325.8 Section 3(a), (b) and (c)](https://www.gsa.gov/portal/directive/d0/content/512516). 54 | - Unwelcome verbal or written comment or physical conduct based on: 55 | - race, 56 | - religion, 57 | - color, 58 | - sex (with or without sexual conduct and including pregnancy and sexual orientation involving transgender status/gender identity, and sex-stereotyping) 59 | - national origin, 60 | - age, 61 | - disability, 62 | - genetic information, 63 | - sexual orientation, 64 | - gender identity, 65 | - parental status, 66 | - marital status, 67 | - or political affiliation. 68 | - Retaliating against anyone who files a formal complaint that someone has violated GSA anti-harassment policies. 69 | 70 | ### Conduct Unbecoming a Federal Employee 71 | 72 | Federal employees can be subject to appropriate discipline, up to and including removal, for conduct unbecoming a federal employee, which is conduct which is unattractive; unsuitable; detracting from one's character or reputation; or creates an unfavorable impression. Abusive and demeaning remarks to and about others in the workplace, and sexual remarks, which do not rise to the level of sexual harassment under the employment discrimination laws, nonetheless can be considered conduct unbecoming a federal employee. 73 | 74 | ### Other Unacceptable Behavior 75 | In addition, the following behaviors violate applicable laws and policies, or otherwise undermine the culture of respect and inclusion we seek to build within TTS: 76 | 77 | - Touching people without their affirmative consent. 78 | - Sustained disruption of meetings, talks, or discussions, including chat rooms. 79 | - Mocking someone's real or perceived accent or first language. 80 | - Repeatedly interrupting or talking over other people in meetings and discussions. 81 | - Negative or offensive remarks based on gender expression, mental illness, socioeconomic status or background, neuro(a)typicality, physical appearance, or body size. 82 | 83 | ## Reporting violations 84 | 85 | The process for reporting violations of GSA's Policy Statement on sexual and non-sexual harassment can be found in [GSA Order ADM 2325.8 Section 3(d)](https://www.gsa.gov/portal/directive/d0/content/512516) and GSA Order HRM 9700.6. Depending on your complaint, you may have a 45-day window from the date of the incident to report it to the GSA. Please read the GSA Order carefully. 86 | 87 | The behaviors listed in this section undermine the culture of inclusion and respect that we are trying to build within TTS. We encourage you to report violations to your supervisor, any management official, a Human Resources official, and/or the Office of Civil Rights, so that TTS can take any necessary steps to ensure that we have a safe and welcoming team. 88 | 89 | ## Credits 90 | 91 | TTS is greatly appreciative of the multiple sources that we drew from to build this Code of Conduct, including: 92 | 93 | - [Code for America Code of Conduct](https://github.com/codeforamerica/codeofconduct) 94 | - [Ada Initiative: HOWTO design a code of conduct for your community](https://adainitiative.org/2014/02/howto-design-a-code-of-conduct-for-your-community/) 95 | - [Geek Feminism Code of Conduct](https://geekfeminism.org/about/code-of-conduct/) 96 | 97 | Laws and Policies Concerning Workplace Harassment: 98 | 99 | - [GSA's Policy Statement on sexual and non-sexual harassment](https://www.gsa.gov/portal/directive/d0/content/512516) 100 | - [Laws enforced by the Equal Employment Opportunity Commission](https://www.eeoc.gov/laws/statutes/index.cfm) 101 | - [Types of Discrimination prohibited by law](https://www.eeoc.gov/laws/types/) 102 | - [New and proposed regulations](https://www.eeoc.gov/laws/regulations/index.cfm) 103 | 104 | ## Version 105 | 106 | Approved May 1, 2018 107 | Published May 7, 2018 108 | -------------------------------------------------------------------------------- /Poliy/OpenSource.md: -------------------------------------------------------------------------------- 1 | # 18F: An Open Source Team 2 | 3 | [18F](https://18f.gsa.gov), a digital services delivery team within the [General Services Administration](http://gsa.gov), develops in-house digital solutions to help agencies meet the needs of the people and businesses they serve. This requires flexibility in how we code, with a focus on lowering costs for the American people, while improving their interactions with the U.S. Government. 4 | 5 | The default position of 18F when developing new projects is to: 6 | 7 | 1. Use Free and Open Source Software (FOSS), which is software that does not charge users a purchase or licensing fee for modifying or redistributing the source code, in our projects and contribute back to the open source community. 8 | 2. Develop our work in the open. 9 | 3. Publish publicly all source code created or modified by 18F, whether developed in-house by government staff or through contracts negotiated by 18F. 10 | 11 | ## Benefits 12 | 13 | Using FOSS allows for product customization, advances interoperability between tools, and improves the overall quality of the final product. Other benefits include: 14 | 15 | 1. **Flexible usage.** The benefits of using FOSS compel 18F to meet user needs by modifying existing or creating new FOSS. FOSS is particularly suitable for rapid prototyping and experimentation. The testing process generates minimal costs, and the process encourages the identification and elimination of defects not recognized by the original development team. 16 | 17 | 1. **Community involvement.** Publicly available source code enables continuous and broad peer review. Whether simply publishing the completed code or opening the development process, the practice of expanding the review and testing process to a wider audience—beyond the development team—ensures increased software reliability and security. Developing in the open also allows for other opinions to help adjust the direction of a product to maximize its usefulness to the community it serves. 18 | 19 | 1. **Cost-savings.** The ability to modify FOSS enables 18F to respond rapidly to changing missions and markets. Support and maintenance of open source code—as opposed to more burdensome usages of proprietary software—provides a real cost advantage where multiple copies of software are required, or when the user base grows. The total cost of ownership is shared with a community, rather than solely 18F. 20 | 21 | 1. **Reusability.** The code we create belongs to the public as a part of the public domain. The code we work on was paid for by the American people, but the end-product is not the only way they should be able to interact with their government. By coding in FOSS, we help populate a larger commons that cities, states, businesses, and individuals can participate in. This creates real economic value by lowering the burden of replicating similar work or by allowing the private sector to build off of and create new businesses around code developed at 18F. 22 | 23 | ## Maximizing Community Involvement and Reuse 24 | 25 | Active involvement from the open source community is integral to the success of open source code. 18F will be an active contributor to FOSS projects that it or its clients utilize. 26 | 27 | Code written entirely by 18F staff will be dedicated to the public domain. In addition, any contracts 18F enters into, where others will develop software on 18F's behalf, will ensure that all results are dedicated to the public domain. In general, all discussion in this document about the licensing of work of 18F's contractors means that 18F will ensure that their contracts guarantee those terms. 28 | 29 | 18F encourages contributions to its open source projects, whether it be code, commentary, bug reports, feature requests, or overall strategic direction. 30 | 31 | Forks or clones of our code repositories are free to be re-distributed. This means code created by 18F can be integrated into work that is under a more restrictive license, even those that are not considered open source licenses. 32 | 33 | This changes when our code repositories include code that was not created by 18F and carries an open license. Code previously released under an open source license and then modified by 18F or its contractors is considered a ["joint work"](http://www.copyright.gov/title17/92chap1.html#101) and must be released under terms permitted by the original open source license. 34 | 35 | The public can use our code as the basis of wholly proprietary and commercial systems. 18F would appreciate that users of our code disclose its lineage, but 18F maintains no legal right to require disclosure. Notifications that our work is used in a new system are always greatly appreciated. 36 | 37 | ## Open Source Licenses 38 | 39 | As previously mentioned, most work generated at 18F falls within the U.S. public domain. 40 | 41 | For our international colleagues, 18F also permanently waives all copyright and related rights worldwide to code created by 18F or its contractors. 42 | 43 | Our [default LICENSE file](LICENSE.md) for projects acknowledges that our work is in the US public domain, and uses [CC0](https://creativecommons.org/publicdomain/zero/1.0/) to waive copyright internationally. 44 | 45 | Our [default CONTRIBUTING file](CONTRIBUTING.md) informs contributors that their contributions will be licensed under the same terms. 46 | 47 | However, certain projects will require the usage of licensed open source software not created by 18F. Some open source licenses make source code available under different terms and conditions. These terms and conditions specify how the code may be used, modified, or shared. When users modify 18F code, they should review and understand the terms of the open source license in question. 48 | 49 | Each project may need to modify or extend the above LICENSE and CONTRIBUTING files as needed for its own circumstances. 50 | 51 | ## Distribution of Code 52 | 53 | There is a misconception that FOSS that is distributed to the public should not be integrated or modified for use in sensitive systems. On the contrary, FOSS is often preferred for use in sensitive systems, due in part to its increased auditability. In other words, security in FOSS must be designed never to rely on obscurity in how the code works. 54 | 55 | In addition, while open source licenses permit the user to modify FOSS for internal use without obligating them to distribute source code to the public, when the user chooses to distribute the modified FOSS outside the user's organization, then the code is subject to whatever license it carries. 56 | 57 | ## Exceptions 58 | 59 | The only conditions where code shall not be developed and released in the open are: 60 | 61 | * The U.S. Government does not have the rights to reproduce and release the item. 62 | 63 | * The public release of the item is restricted by other law or regulation, such as the Export Administration Regulations or the International Traffic in Arms Regulation. 64 | 65 | These decisions will be made as needed by the 18F Infrastructure team, which will lead an interdisciplinary team to review the conditions under which code will not be made available publicly. Any further exemptions will be rare, documented publicly, and the result of compelling interest. 66 | 67 | If an existing solution cannot be found in the open source community, 18F may consider other options, including creating an open source solution itself. Ultimately, the software that best meets the needs and mission of 18F should be used. 68 | 69 | ## Further Reading 70 | 71 | [OMB M-16-21](https://sourcecode.cio.gov/) - A White House policy pertaining to federal source code, published by the White House Office of Management and Budget. M-16-21 directs all agencies to publish some custom developed code as open source code, to update acquisition requirements to capture code developed by vendors for GSA, and to inventory [all open- and closed-source code](https://open.gsa.gov/code.json). 72 | 73 | [GSA Open Source Policy](https://open.gsa.gov/oss-policy/) - GSA's agency-wide open source policy, created based on OMB's M-16-21 policy. 74 | 75 | ## Thanks 76 | 77 | 18F would like to thank the Consumer Financial Protection Bureau, Department of Defense, and Office of Management and Budget for their work in blazing the path for the use of FOSS in the Federal Government. 78 | 79 | ## Future Changes 80 | 81 | This policy is a living document. 18F expects to make changes to this policy in the future, and we welcome [issues](https://github.com/18f/open-source-policy/issues) and pull requests. To contact us privately, email 18F@gsa.gov. 82 | -------------------------------------------------------------------------------- /Practice/OpenSourcePractice.md: -------------------------------------------------------------------------------- 1 | # Practicing our open source policy 2 | 3 | This document is meant to give specific team guidance on putting our [open source policy](policy.md) into practice. 4 | 5 | * 18F releases software into the [international public domain](#public-domain). 6 | * All team members should feel empowered to contribute back to outside open source projects. 7 | * We [develop our software in the open](#working-in-public), while also [protecting sensitive information](#protecting-sensitive-information). 8 | * There are [narrow, documented exceptions](#exceptions) where we may delay or withhold source code. 9 | 10 | 18F team members should work with the strong presumption that all of their code will be public, throughout and after development. 11 | 12 | Before deciding to delay or withhold the release of source code, consult with the team and be prepared to publicly document this exception. 13 | 14 | ## Public domain 15 | 16 | [By law](http://www.law.cornell.edu/uscode/text/17/105), works of the United States government are not copyrightable in the US, and so are public domain. But by default, US government works **are** copyrightable internationally, and so 18F intentionally waives this copyright abroad using [Creative Commons Zero (CC0) 1.0](https://creativecommons.org/publicdomain/zero/1.0/). 17 | 18 | There are potentially other cases where copyright is involved: where contractors produce the work, or where work was otherwise originally performed not in the capacity of a US government employee. 19 | 20 | To the extent 18F has the rights to do so, 18F will normalize the copyright status of its work product under CC0. 21 | 22 | ## Contributing back to outside projects 23 | 24 | 18F staff are encouraged to seek existing, open source solutions -- whether government or non-government -- before writing custom tools. When existing libraries need to be modified or improved, 18F staff should make the modifications with eventual upstream contribution in mind. 25 | 26 | In practice, this generally involves forking the relevant repository to the 18F organization within GitHub, creating a new branch with the modifications, and sending a pull request to upstream from the 18F fork. Unlike our own projects, there is no need for internal code review in this scenario (though it doesn't hurt). 27 | 28 | In terms of licensing: as works of the government, employee contributions are public domain in the United States, regardless of the outside project's contribution agreement. This does not change the overall license status of the outside project. 29 | 30 | As [the Free Software Foundation says](https://www.gnu.org/licenses/gpl-faq.html#GPLUSGovAdd) about government-contributed improvements to GPL software: 31 | 32 | > Yes. If the improvements are written by US government employees in the course of their employment, then the improvements are in the public domain. However, the improved version, as a whole, is still covered by the GNU GPL. There is no problem in this situation. 33 | 34 | See also: [The Department of Defense's FAQ question about this](http://dodcio.defense.gov/Open-Source-Software-FAQ/#Q:_Can_government_employees_contribute_code_to_open_source_software_projects.3F). 35 | 36 | ### Contributor License Agreements (CLAs) 37 | 38 | Some external projects have CLAs. You cannot sign these yourself, in your official capacity. 39 | 40 | 1. See if there is an organizational CLA available. 41 | 1. Send the agreement to GSA's Office of General Counsel (OGC) for review. 42 | * Ask in [#wg-opensource](https://gsa-tts.slack.com/messages/wg-opensource) or [#legalstuff](https://gsa-tts.slack.com/messages/legalstuff) for who the best contact is. 43 | 1. Collect names/emails/GitHub usernames (whatever is needed) for folks you think will be contributing. 44 | * Usually easier to add too many than too few. 45 | 1. Get it signed. 46 | 1. Add to list below. 47 | 1. Contribute. 48 | 49 | 18F currently has the following CLAs signed: 50 | 51 | * [Cloud Foundry Foundation](https://www.cloudfoundry.org/governance/#docs) ([revised](https://drive.google.com/file/d/0B0wktDTPk3gTVFNJX0VtYndWMHJPdHRwdkN5VjVsLUNVa3lv/view)) 52 | * [Google](https://cla.developers.google.com/clas) 53 | * Join the [open source contributors Google Group](https://groups.google.com/a/gsa.gov/forum/#!forum/oss-contributors) 54 | 55 | ## How to license 18F repos 56 | 57 | When creating a repo, add a [LICENSE.md](LICENSE.md) and [CONTRIBUTING.md](CONTRIBUTING.md) file, and add/edit the [README.md template](README_TEMPLATE.md). 58 | 59 | The preceding links are to our standard boilerplate for each of those, so you can just copy and paste them. In some cases, you may need to customize them for your use -- for example, if you've forked a project that originated from outside the government. 60 | 61 | You may wish make the following shell aliases 62 | 63 | ```bash 64 | alias insert-license="curl -sO https://raw.githubusercontent.com/18F/open-source-policy/master/LICENSE.md" 65 | alias insert-contrib="curl -sO https://raw.githubusercontent.com/18F/open-source-policy/master/CONTRIBUTING.md" 66 | alias 18f-init="insert-license && insert-contrib && echo 'Licensed.'" 67 | ``` 68 | 69 | You can then initialize a new 18F repository's license information with: 70 | 71 | ```bash 72 | 18f-init 73 | ``` 74 | 75 | Want to take it even further and create the repo at the same time? 76 | 77 | ```bash 78 | alias create-repo="mkdir \!* && cd \!* && git init ." 79 | alias create-readme="curl -s https://raw.githubusercontent.com/18F/open-source-policy/master/README_TEMPLATE.md -o README.md" 80 | alias create-18f-repo="create-repo \!* && 18f-init && create-readme && sed 's/[Repo Name]/$(/usr/bin/basename $(pwd))/' README.md && git add . && git commit -m 'initial commit'" 81 | ``` 82 | 83 | Then create a repo and license it with: 84 | 85 | ```bash 86 | create-18f-repo new-project-name 87 | ``` 88 | 89 | Even if you don't create a repo, it's recommended to use [this README.md template](README_TEMPLATE.md) that sums up what's going on. 90 | 91 | ## Accepting contributions from the public 92 | 93 | Any 18F project can (and should!) accept open source contributions from the public. 94 | 95 | Projects can **encourage public contributions** by: 96 | 97 | * Creating open issues where public help would be especially welcome. 98 | * Labeling those issues with `help wanted` so people can scan issues quickly and [services](http://www.codeforamerica.org/geeks/civicissues) can aggregate volunteer opportunities. 99 | * Asking for contributions, in the README and in other public writing about the project. 100 | * Providing solid documentation for any project setup process. 101 | * Being super nice when communicating with volunteers. 102 | 103 | As [described above](#public-domain), 18F projects are dedicated to the international public domain wherever possible. In this situation, contributors must agree to release their contributions into the international public domain. Projects can inform contributors of this agreement by copying the [`CONTRIBUTING.md`](CONTRIBUTING.md) file from this repo into new project repos, and copying the ["Public domain" section of this repo's README](README.md#public-domain) into the new project's README. 104 | 105 | When an 18F project has a non-standard license status (e.g. it's a fork of a previously licensed project, or is a module/plugin for a GPL project), then that project needs to figure out an appropriate contributing agreement. 106 | 107 | ## Working in public 108 | 109 | 18F believes in [working in public](https://18f.gsa.gov/2014/07/31/working-in-public-from-day-1/). It creates a healthier working environment, a more collaborative process, and just better software. 110 | 111 | All 18F team members are expected to make new source code repositories public from the time of creation. This means we often publish drafts in our repos that may change substantially. If you're interested in learning more about the contents of a repo, email 18F@gsa.gov and we'll direct you to the right person or team. 112 | 113 | ## Protecting sensitive information 114 | 115 | As part of responsibly working in the open, 18F team members are expected to protect information that needs to be protected. We already receive training and guidance about information we can’t publish for [ethical](https://www.oge.gov/web/oge.nsf/Topics), [legal](https://handbook.18f.gov/intro-to-18f-infrastructure/), and [security](https://insite.gsa.gov/portal/content/627226) reasons — this section is a reminder about sensitive information (formally called “[controlled unclassified information](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171.pdf)”) to carefully protect when working with our open source projects. Sensitive information can include code, configuration, content, or documentation. (We have [approved options for sharing sensitive information](https://handbook.18f.gov/sensitive-information/).) 116 | 117 | If 18F team members aren't sure whether they should make something public, they should ask a person on our 18F Infrastructure team for advice _first_. (Try asking in [#infrastructure](https://gsa-tts.slack.com/messages/infrastructure), but ask a general question about the type of information, instead of pasting the actual information, since we can't put sensitive information in Slack.) 118 | 119 | If 18F team members inadvertently come into the possession of classified information (Secret, Top Secret, etc.), they should immediately follow our [security incident process](https://handbook.18f.gov/security-incidents/). 120 | 121 | Sensitive information we need to protect includes, but is not limited to: 122 | 123 | * Information an attacker could plausibly use to help them compromise any system (including a prototype/development system). Examples: 124 | * **Secret keys:** Passwords, passcodes, access codes, access tokens, API keys, TLS keys, SSH keys, OAuth secrets, or any other “secret keys” that protect access to something. 125 | * **Undisclosed vulnerabilities:** If we know of a security problem or potential security problem with our code that isn’t already publicly-known (such as a vulnerability that can’t be found with a publicly-available open source scanning tool run on the public-facing system), we shouldn’t write publicly about it until we fix it. 126 | * Nonpublic information in general about vulnerabilities, including attribution/source information (such as how and when we learned about a vulnerability, if the disclosure to us was not public). 127 | * We may wish to withhold some non-18F IP addresses. If something looks like an IP address, ask 18F Infrastructure before publishing that info. 128 | * Personally Identifiable Information (PII). Here’s [OMB's definition and GSA's policy](http://www.gsa.gov/portal/content/104256). 18F also has [guidance for systems involving PII](https://pages.18f.gov/before-you-ship/security/pii/). 129 | * Some kinds of procurement and acquisition information, which may include non-public cost or pricing data, contract information, trade secrets, indirect costs, and direct labor rates. If you’re an 18F team member working with this kind of data, ask our acquisition specialists ([#acquisition](https://gsa-tts.slack.com/messages/acquisition/)) for help determining whether it can be public. 130 | * Emergency procedures, such as evacuation plans. 131 | 132 | There are more categories of controlled unclassified information to protect; those are just the kinds that we work with most often. [Here’s the complete list.](https://www.archives.gov/cui/registry) 133 | 134 | ## Private repositories 135 | 136 | If the 18F Infrastructure team determines that a repository should not be public, as described in the [open source policy](policy.md#exceptions), the reasoning should be documented and a link to that reasoning provided in the repository's `README` to preserve that knowledge and so the decision can be revisited in the future if circumstances change. If the underlying reasons for making the repository private are not themselves sensitive, this explanation can be placed directly in the `README`. 137 | 138 | ## Managing 18F resources 139 | 140 | 18F intends to produce great software for the American people. That means not just rushing through projects to get them working as fast as possible, but managing [technical debt](https://en.wikipedia.org/wiki/Technical_debt) with an eye towards usability and reusability. 141 | 142 | If a refactoring or feature makes the tool easier for 18F to use in its work, and the teammate doing it is otherwise meeting their duties, then that's time well spent for 18F and the taxpayer. 143 | 144 | Open source projects can — and hopefully do! — get use and uptake from outside 18F. It's also okay for individual teammates to create projects they intend to use both at 18F and in their personal capacity. 145 | 146 | Teammates do not need permission to start new open source projects in the 18F GitHub organization. However, generally speaking, these projects should have some work applicability. 147 | 148 | When creating new open source projects: 149 | 150 | * If you're creating a repo because it's primarily for your 18F work, and the work you perform in it is primarily to benefit 18F, start the repo's life in the 18F organization. It's okay if you also think it'll be helpful in personal work. 151 | * If you're creating a repo that isn't primarily for 18F work, but you think will likely see use at 18F, start it in your personal account. If you don't have strong feelings or concerns about ownership, consider releasing the project under CC0 to save yourself even having to ever think about it. 152 | 153 | As people open issues and request features (no matter whether the repo is in your account or 18F's), continue to exercise professional judgment about how to spend 18F time. 154 | 155 | If you think something will benefit 18F and is worth the time, then that's valuable 18F work. If it won't benefit 18F but makes the library better for other uses, that may best be done with personal time. 156 | 157 | ## Archiving a repository 158 | 159 | When a repository is no longer useful, it should be [archived](https://help.github.com/articles/archiving-repositories/). This may be because the work has been incorporated into another repository, the project is unmaintained and out-of-date, or some other reason. In order to preserve repository metadata like pull request discussions and issues, the repository should not be deleted or made private. 160 | 161 | ## Exceptions 162 | 163 | 18F currently has **no projects** for which we will not ever release the source code. 18F has two projects where source code will be released at a later time: 164 | 165 | * [login.gov](https://login.gov) - The infrastructure code was created in private repositories, though [much of their other code](https://github.com/18F?q=identity) is open source. 166 | * [US Citizenship & Immigration Services](https://www.uscis.gov/) - Project agreement pre-dated the creation of 18F's open source policy. 18F will work with USCIS to coordinate publication of source code as components are publicly released. Components based on existing open source projects will remain open throughout development. 167 | --------------------------------------------------------------------------------