Git Product home page Git Product logo

projects's Introduction

18F Projects

We have hundreds of repos and have released dozens of tools but they're hard to find unless you know where to look (or what you're looking for.)

We are now creating a way to surface and discover the projects that 18F works on. You will be able to easily find how each engagement and repo works, who works on it, and how to contact the team that created it.

This is an ongoing work in progress!!! Our Wiki contains research notes and drafts that you might find helpful if you're also thinking about discovery.

Dependencies

Running Locally

$ virtualenv -p python3.5 venv
$ source venv/bin/activate
$ pip install -r requirements.txt

$ createdb 18fprojects

$ python manage.py migrate
$ python manage.py runserver

Fixtures containing all possible federal clients and 18F business units are included. To load:

$ python manage.py loaddata projects/fixtures/*.json

Sample project data may also be imported from a CSV file. If you are in 18F, export the first sheet of this Google spreadsheet as a CSV, then run the following command:

$ python manage.py import_projects filename.csv

To load data from our S3 bucket, the following env vars are needed:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_BUCKET

Using Docker (optional)

A Docker setup potentially makes development and deployment easier.

To use it, install Docker and Docker Compose. (If you're on OS X or Windows, you'll also have to explicitly start the Docker Quickstart Terminal, at least until Docker goes native.)

Then run:

docker-compose run app python manage.py migrate

Once the above command is successful, run:

docker-compose up

This will start up all required servers in containers and output their log information to stdout. If you're on Linux, you should be able to visit http://localhost:8000/ directly to access the site. If you're on OS X or Windows, you'll likely have to visit port 8000 on the IP address given to you by docker-machine ip default. (Note that this hassle will go away once Docker goes native for OS X/Windows.)

Accessing the app container

You'll likely want to run manage.py to do other things at some point. To do this, it's probably easiest to run:

docker-compose run app bash

This will run an interactive bash session inside the main app container. In this container, the /projects directory is mapped to the root of the repository on your host; you can run manage.py from there.

Note that if you don't have Django installed on your host system, you can just run python manage.py directly from outside the container--the manage.py script has been modified to run itself in a Docker container if it detects that Django isn't installed.

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.

projects's People

Contributors

brendansudol avatar jseppi avatar thisisdano avatar toolness avatar

Stargazers

 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

projects's Issues

Export .about.yml files to project repositories?

@ccostino mentioned that the about.yml specification and the convention of adding .about.yml files to project repositories is actually part of the ATO checklist for projects.

This means that if we store the canonical data in the projects db instead of .about.yml files, we might mess up the ATO process.

One option is to change the ATO process, which could be hard.

Another option, though, is to actually have projects auto-generate .about.yml files and commit them to project repositories. These auto-generated files can have comments on the top instructing readers to not modify them directly, but instead edit the data via the projects admin UI.

Thoughts on this @gboone @brendansudol?

Rename this repository?

So on Slack I mentioned that now i am sorta wishing we called this project something other than projects, because I keep reading "projects" as "list of projects", not "the project known as projects". 😅

At least on the Web I can typeset the name in monospace (e.g. projects) to disambiguate, but it might get really confusing in face-to-face/audio interactions.

Since this project is still in very early stages, should we just go ahead and rename it now, to avoid confusion?

write access?

@brendansudol trying to push up a branch to remote and getting a permission denied. thinking i don't have write access to the repo?

Make Project.billable a boolean

As mentioned here:

This is unintuitive to me--is there a reason we didn't make billable a boolean field? And even if it has to be a choice field, it's a bit unintuitive that billable is 0 and non-billable is 1. This means that the following code:

if project.billable:

will actually be checking if the project is NOT billable... 😖

This will require a schema migration and a data migration, I think.

Retry connection to db when in docker

This is done in 18F/tock#359, would be great to port the change here as well. Will also need to remove the mention of running manage.py migrate twice in the readme.

Or, alternatively, all this code is getting a bit unwieldy, so perhaps it might be a good time to factor it out into a separate pip package?

Add an API

Hey, I just wanted to add an issue for this to make sure that the work/thought we've done so far on it doesn't get buried in history.

Work was started on an API in #16. However, we didn't have a concrete use case for the API. As the 18F API Standards state:

The best way to understand and address the weaknesses in an API's design and implementation is to use it in a production system.

Whenever feasible, design an API in parallel with an accompanying integration of that API.

Since we didn't have an accompanying integration of the API, we decided to close the PR for now, but pick up work on it whenever we actually have a concrete need for an API.

Pull information about people from the Team API?

In order to create valid about.yml files for #18, and surface more information about who's responsible/PoC for projects in general, it might be helpful to have more metadata about people.

One way to do this may be to keep the Team API as the source of truth about individuals, but create a model for it in the DB and regularly update it by polling the Team API.

I have experience with the Team API so I could do this one if it sounds like a good idea.

Add bandit to travis

jacobian mentioned that https://github.com/18F/bug-bounty has a pretty good setup involving unittest, flake8, and bandit that sets up and runs easily on both travis and locally (see particularly tox.ini, .travis.yml, and CONTRIBUTING.md for the howto).

Images associated with each project?

Should there be screenshots available with each project? If so, what dimensions would be the most useful? (And I supposed we might need to add an upload field.)

Collecting backlog.

We're starting to come up with really good ideas for the dashboard and I want to ensure that we're capturing our backlog. Should we use the Wiki? Issues, tagged in a certain way? Trello? Something else?

Add validation/cleaning logic for GitHub URLs

In #5 we added a "GitHub URL" field for projects, but it should probably be validated, so that if someone pastes in a link that's not of the form https://github.com/{ORG}/{REPO}, we reject it. Or, alternatively, normalize it if we can.

Enable Content Security Policy

It also looks like Django 1.10 alpha 1 removes all inline JS from django-admin, according to the release notes! (In the meantime, though, we will need to not deliver the CSP headers at the /admin/ endpoint, I guess. 😞)

Add non-MVP fields to models

  • Tags: drop-down menu of tags
  • Contact: email address or GitHub issue
  • Status: active or non-active
  • Requesting agency: select from dropdown
  • Business unit fulfilling request: select from dropdown
  • Contributors: pull from GitHub API
  • Popular: pull stars / forks from GitHub
  • How can I learn more? Link to GitHub Issues page
  • How can I help? Pull issues from that GitHub page labeled ‘help wanted’

Determine and then add tags or some way to categorize

Thinking about how to tag our projects will be key to discovery mechanisms.

Two thoughts: the fewer categories, the better. @brittag smarted suggested grouping projects into three categories: Learn and Use, Partner, and Contribute.

“Contribute to 18F” might encompass micropurchase and Open Opportunities options (and the future bug bounty program) as well as contributing to our open source projects?

“Partner with 18F: learn about our projects with agency partners (both completed and in progress)”

“learn from 18F and use its materials”: material that's reuseable from other organizations.

I really like the idea of keeping this minimal, but would like @thisisdano's thoughts on this approach.

Alternatively or in addition, we could give people a dropdown list of tags from the blog: https://18f.gsa.gov/tags/ - This might also be a way to bring in related material from the blog. We would likely want to continually refresh this blog tag list, if new tags are added to the blog. (Not sure if this is the right approach or one we should take, just throwing it out there for preliminary discussion.) @gboone

Only make certain fields editable by non-admins

Certain fields should never change:

  • Name
  • Slug
  • Client
  • Tock ID
  • Cloud.gov project

Other fields may change, but should require approval by someone at the admin level:

  • Tagline
  • Project lead
  • Description
  • Impact
  • Live URL
  • GitHub URL(s)

Fields that may change:

  • Status
  • Billable

We should think about how to create a system to allow edits to be approved through an admin layer, or some other means of ensuring that everyone cannot edit every field — because that might cause errors with Tock and/or other places where we have this material. Is there a way to lock certain fields?

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.