Giter Site home page Giter Site logo

open-source-guide's Introduction

18F Open Source Style Guide

This guide helps people document code repositories so that they're easy to use and understand. In each section, we outline our strategies for making sure that our code repositories are clear, accessible, and user-friendly.

It’s important to make sure our documentation is clear both for internal and external audiences. As our team expands, we want our new employees to easily find and use our existing codebases.

It's also really important if we want to make outside contributors feel welcome or have outside organizations fork and use our code. (And we do!) Explaining what a project is, why it's important, and how people can help ensures that people can fork and adapt our projects.

(Fork means to copy the code that exists over to your own repo, or repository of code, so that you can adapt or use it as needed.)

This guide also contains a checklist we created that helps ensure our repos are clear, accessible, and user-friendly. Some terminology used may be GitHub-specific, but the concepts are applicable regardless of your version control system or platform. We wrote it so that both non-coders and coders can understand it. (If something is not clear, please let us know.)

We’re sharing it because it we think it’s helpful for lots of organizations, including our own. We know that many of our repos don’t conform to this exact style. By articulating a specific style, we hope this document will also help us improve our own practices.

How to use this guide

We created this guide for reference on an as-needed basis. It’s here when you’re wondering how to describe a repo, for instance, or when you’re wondering how to create a friendly, informational tone when writing issues for users.

To this end, we’ve structured the guide into descriptively named sections. Browse our table of contents to find the topic you’re looking for.

Most importantly, we encourage you to make a copy of this document and adapt it to your organizational needs. This guide is just that: a guide. It’s not meant to provide the final opinion on any of the topics discussed. If a certain section isn’t relevant to you and your team, delete it. And if you feel the guide is missing a section, by all means, add it by clicking 'edit this page' at the bottom of every page. This guide is yours to use, and we trust you’ll update it in the ways that best suit you.

Public domain

This project is in the worldwide public domain. As stated in CONTRIBUTING:

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

How to run a local copy of this guide

(Instructions adapted from the 18F Documentation Working Group.)

You will need Ruby ( > version 2.1.5 ). You may consider using a Ruby version manager such as rbenv or rvm to help ensure that Ruby version upgrades don't mean all your gems will need to be rebuilt.

On OS X, you can use Homebrew to install Ruby in /usr/local/bin, which may require you to update your $PATH environment variable:

$ brew update
$ brew install ruby

To serve the site locally:

$ git clone [email protected]:18F/open-source-guide.git
$ cd open-source-guide
$ ./go serve

This will check that your Ruby version is supported, install the Bundler gem if it is not yet installed, install all the gems needed by the template, and launch a running instance on http://localhost:4000/. (Make sure to include the trailing slash! The built-in Jekyll webserver doesn't redirect to it.)

After going through these steps, run ./go to see a list of available commands. The serve command is the most common for routine development.

How to create your own guide

This guide is based on the DOCter template created by the Consumer Financial Protection Bureau (CFPB). Our canonical adaptation of DOCter is contained in the 18F Guides Template.

Contact us

If you'd like to contact us, please create a GitHub issue or email [email protected]. Thank you!

open-source-guide's People

Contributors

afeld avatar beardicus avatar gbinal avatar mbland avatar nicoleslaw avatar tmcw avatar yozlet avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

open-source-guide's Issues

Govfresh suggestions to make guide more helpful

Additional thoughts that would make the guide more helpful from Govfresh:

  • Add a section on collaborators and permissions.
  • Encourage including a link for the ‘Website for this repository’ next to the description whenever possible.
  • Next to the ‘Edit this page’ link, add a ‘Submit feedback’ link to the issues section for the guide so it’s easier to giv feedback. In general, if you’re going to have either option, it’s best to have both, especially the latter.
  • One bug: The images on https://pages.18f.gov/open-source-guide/using-the-wiki aren’t responsive.

Add guidance for all the things our software should ship with

Karl Fogel's "Producing Open Source Software" recommends each open source software package include a:

  • README file
  • INSTALL file
  • LICENSE file
  • CHANGES file (CHANGELOG or NEWS)

See: http://producingoss.com/en/producingoss.html#packaging

In the top level of new directory tree, there should be a plain text README file explaining what the software does and what release this is, and giving pointers to other resources, such as the project's web site, other files of interest, etc. Among those other files should be an INSTALL file, sibling to the README file, giving instructions on how to build and install the software for all the operating systems it supports. As mentioned in the section called “How to Apply a License to Your Software” in Chapter 2, Getting Started, there should also be a COPYING or LICENSE file, giving the software's terms of distribution.[64]

There should also be a CHANGES file (sometimes called NEWS), explaining what's new in this release. The CHANGES file accumulates changelists for all releases, in reverse chronological order, so that the list for this release appears at the top of the file.

Spelling of FAQ

I make the recommendation to change the spelling of FAQ. Do not use "FAQS", "FAQs", or "faqs". Many styleguide experts argue for the "s". This is a personal preference. Looks cleaner and historically seems to be the original presentation.

Suggestions for naming?

I was hoping you all might be open to discussing a few slightly more prescriptive guidelines for naming conventions. There are two areas in particular that I think are problematic in our industry with regard to naming, which makes projects especially hard to find (especially if you're looking for docs or support) :

  1. Avoid "clever" naming. The world has a lot of projects with puns in the name or other cleverness that makes them rather hard to find. For example, the number of Javascript projects with some coffee-pun in the title is enormous. It'd be useful if developers were encouraged to avoid names that are just jokes and ambiguous. (I'll take postgresql-node-session-connector over Barista any day.)

  2. Check to see that the name isn't already used. I've brought this up before but it's also really hard to find projects when they're using a name that's already used by another highly-used project. A quick google search before deciding on a name can save lots of time for your users later.

As a person who is setting up their first open-source repo, I'd like to know if there's any actions I should take to make my repo more friendly for people to submit issues to.

I've read the sections on structuring my own issues and creating README's, but is there anything that I can and should do to help structure how people submit issues before the repo is live?

For issue submitters, I'd like to make that experience a positive and easy one.
For my project team, I'd like to make sure that we receive issues and feedback that we can make actionable.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.