Closed ultrasaurus closed 8 years ago
Who is the audience for the stages section?
@ultrasaurus I want to wait until the stakeholders hash this out: https://github.com/18F/about_yml/pull/12/files#r41916977 before tackling an example. Not sure who to push for final decisions. (Or do you see this as something that will help those decisions surface?)
@melodykramer I think we're thinking this might help hash out those decisions. I'm speaking with @brethauer about getting some UX folks to help organize and facilitate a Mural.ly session with representatives from across the team so that we can come to a shared understanding of project classifications and repo groupings, but it might help to have some ideas in-pocket.
I would suggest doing the following on each child page - changes are in bold.
Full proper name of the child repo:
full_name:
Name of the main parent repo if this is a sub-repo:
parent:
Maturity stage of child repo (required) values: discovery, alpha, beta, live stage:
Whether or not the child repo is actively maintained (required) values: active, deprecated status:
Description of child repo and how it fits into main repo
description:
On the main project page, I would suggest having the following:
Name of project Description of Project Type of content in repo Who owns repo
{{ if child repos exist }}
Full name of child repo with link Description of child repo and how it fits into main repo Maturity stage of child repo Whether or not child repo is actively maintained
{{ end if child repo exists}}
Team members Partners Descriptions of developments Technologies Impact/Outcomes of Project Services used to supply project status Licenses Blogs or websites associated with projects Project Artifacts Email addresses for POC
@melodykramer Would you be up for writing an example for a project or two so we can see what this would look like with content?
parent repo model: https://gist.github.com/melodykramer/2c4aeabd2b17e8df5960
child repo model: https://gist.github.com/melodykramer/33ac2e19c40702a7a952
The child repo would only be visible if it exists and only the data mentioned in the previous comment would be visible. The two repos would be linked by the id.
Waiting for the card sorting on 11/3
This is related to https://github.com/18F/dashboard/issues/305.
There are two related but different concepts of parent to child that we are conflating at the moment:
See the Midas example for a demonstration of both.
I think we could model both with the fields we have if we pay attention to the absence of information.
For example, if an about.yml include just the full_name
and parent
, it gets listed in the code
section of the listed parent. Otherwise, it is listed as a subproject. I'm not sure I like this approach, but I think it'd work.
Another option would be to use the .about.yml links
section. We could add a repo
type, and put those links in the code block.
the code to support multiple repos is now live in dashboard, separate issues exist for the content changes
If a project has multiple github code repositories, we should be able to show them on the dashboard page in a way that feels natural to the 18F product leads, as well as developers on the project and doesn't confuse non-technical agency partners (who aren't the primary audience for this data, but need to be peripherally aware of it, so they can point their developers to it as needed).