18F / dashboard

DEPRECATED: A site to track our projects' status and much, much more...
Other
44 stars 25 forks source link

./go update_data will import /projects yaml files #180

Closed ultrasaurus closed 9 years ago

ultrasaurus commented 9 years ago

this is an idea of how to approach #179

ultrasaurus commented 9 years ago

The idea is that individual projects can add a project yaml file in https://github.com/18F/data-private/projects and it would override what's in private/projects.yaml which in turn overrides the dashboard/_data/projects.yml

ultrasaurus commented 9 years ago

I pushed my example data here: https://github.com/18F/data-private/tree/midas-project-file but didn't do a pull request of that, until I hear back on this idea

gboone commented 9 years ago

From #179:

don't know what Jekyll will do with a collision between NAME.yml and NAME/

Not sure if this is what you meant, @mbland but I think it is: creating _data/projects/<project>.yaml overrides projects.yml as the source of site.data.projects and thus breaks the template. :neutral_face:

I like this idea and am definitely sympathetic to the issue and so will leave this and #179 open so we can iterate on the idea. (Though, it's probably a better idea to do that iterating in data-private.)

Proposal: Write a script that essentially shatters the existing projects.yaml and creates all the individual project files in data-private. Then use HashJoiner to sew them all back into one data file for deployment to various different spots.

gboone commented 9 years ago

Working through the following error: Assuming a myra.yml file in _data/private/projects/ with the name matching the myra entry in _data/private/projects/.

./go update_data
./import-public.rb:26:in `[]': no implicit conversion of String into Integer (TypeError)
    from ./import-public.rb:26:in `block (2 levels) in <main>'
    from ./import-public.rb:26:in `index'
    from ./import-public.rb:26:in `block in <main>'
    from ./import-public.rb:19:in `each'
    from ./import-public.rb:19:in `<main>'
ultrasaurus commented 9 years ago

I tested the pull request with a midas.yml file in dashboard/_data/private/projects

- project: "Midas"
  name: midas
  github:
  - 18F/midas
  description: Midas is a platform that facilitates collaborative work worldwide. Individuals can create projects, propose working groups, or assemble "tiger teams" to act on their ideas. Anyone can also post tasks online and people with the requisite skills can respond and complete the task.
  partner:
  - General Services Administration
  - Department of State
  - Department of Health and Human Services
  partners:
  stage: beta
  impact: "2 million federal employees"
  milestones:
  - "October 2014: GSA hosts Midas open source hack night in DC"
  - "October 2014: DigitalGov Open Opportunities pilot starts"
  - "September 2014: GSA OCSIT signs MOU for Open Opportunities to move to Midas platform"
  - "September 2014: 18F launches https://midas.18f.us for use by early adopters"
  - "June 2014: State Department launches Alpha as Crowdwork"
  - "May 2014: HHS launches Alpha as FairTrade"
  - "January 2014: 18F begins work on project"
  - "June 2013: State Department begins project Discovery stage with Presidential Innovation Fellows"
  contact:
  - midas@gsa.gov
  stack: "JavaScript (Node/Sails, Backbone), CSS, Chef"
  team: sarah, david, joe, dhcole
  licenses:
    midas: Public Domain (CC0)
  links: https://midas.18f.us/
  blog:
  - midas
  status:

@gboone what was the content of the myra.yml file you were testing?

gboone commented 9 years ago

Okay, my mistake was I didn't make a full copy of the data from `projects.yml'.

If we merge this today we'll want to let product owners know that they need to copy the full entry from projects.yml into the new projects/<project>.yml file. That is, a myra.yml that looks like this:

---
- project: myRA
  name: myra
  github:
  - 18F/18f.gsa.gov

Will not merge the new github repo into the existing projects.yml entry. It will completely overwrite it. Personally, I'm not a fan of that, but you're the product lead, so if you don't think people will be confused I'm okay with merging it.

ultrasaurus commented 9 years ago

@gboone looks like our comments cross in transit. I'm a fan of having all my data in one place -- I would delete the midas entry from the projects.yml in my first commit, then after that, I wouldn't have any collisions

Thanks!

mbland commented 9 years ago

@gboone:

Proposal: Write a script that essentially shatters the existing projects.yaml and creates all the individual project files in data-private. Then use HashJoiner to sew them all back into one data file for deployment to various different spots.

If you can bang that out as part of this PR, you can check in the script and the "shattered" files all in one shot.

gboone commented 9 years ago

Yeah, I'm thinking that might be better done in the data-private repo where people will be editing them. Doesn't mean I won't do it (soon), just not in this PR.

mbland commented 9 years ago

@gboone Shall you open an issue in data-private, or should I?

gboone commented 9 years ago

I can do it.

ultrasaurus commented 9 years ago

Thanks!

gboone commented 9 years ago

Thanks for the contribution!