search

18F / dashboard

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

If a project has multiple github code repositories, we should be able to show them... #267

Closed ultrasaurus closed 8 years ago

ultrasaurus commented 8 years ago

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).

melodykramer commented 8 years ago

Who is the audience for the stages section?

melodykramer commented 8 years ago

@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?)

mbland commented 8 years ago

@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.

melodykramer commented 8 years ago

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:

melodykramer commented 8 years ago

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

ultrasaurus commented 8 years ago

@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?

melodykramer commented 8 years ago

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.

DavidEBest commented 8 years ago

Waiting for the card sorting on 11/3

DavidEBest commented 8 years ago

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.

DavidEBest commented 8 years ago

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.

ultrasaurus commented 8 years ago

the code to support multiple repos is now live in dashboard, separate issues exist for the content changes