Multiple repos for a project

[adamralph]

E.g. for ConfigR I have up-for-grabs labels in two repos, so I'd like to have two links. I guess I could add a whole separate "ConfigR Samples" entry but it would be nicer if both links were somehow shown against the single ConfigR entry.

I.e.

https://github.com/config-r/config-r/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs

and

https://github.com/config-r/config-r-samples/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs

[shiftkey]

I guess the only hassle here is turning this element:

upforgrabs:
  name: up-for-grabs
  link: https://github.com/config-r/config-r/labels/up-for-grabs

Into something more like a dictionary (I'm not even sure if this is valid YAML):

upforgrabs:
  - { project: core, name: up-for-grabs, link: https://github.com/config-r/config-r/labels/up-for-grabs }
  - { project: samples, name: up-for-grabs, link: https://github.com/config-r/config-r-samples/labels/up-for-grabs }

Will think about this some more (having a separate project is a workaround, but doesn't help for maintainability and associating these two things).

[adamralph]

Yeah, I can't claim to have thought it through very far.

The syntax highlighting suggests that it isn't valid YAML 😉

How about this:

upforgrabs:
  core:
    name: up-for-grabs
    link: https://github.com/config-r/config-r/labels/up-for-grabs
  samples:
    name: up-for-grabs
    link: https://github.com/config-r/config-r-samples/labels/up-for-grabs

[shiftkey]

I'd like to confirm that the upforgrabs element remains enumerable before we go down this path (otherwise generating the site content is going to be a pain) and also setup some CI hooks to verify that a PR contains valid YAML (so others know their PRs are structured right, and we don't accidentally merge a PR and break the site).

[adamralph]

Given that the schema would change from...

upforgrabs:
  name:
  link:

to

upforgrabs:
  project1:
    ...
  project2:
    ...

... I guess you'd have to migrate all the current entries to the new schema. Otherwise, you'd have to special case the "project names" name and link. Alternatively, you could use a new element instead of upforgrabs.

[shiftkey]

We could have some conventions (say default for the root element) to help with migration, but for the 80%* who don't have multiple projects they need to understand this. Or perhaps we do away with the upforgrabs element altogether? I'm not sure, need to think more on it.

* made up stat

[dahlbyk]

Don't we just JSONify the YML? Making the JS that consumes it robust against both structures would not be difficult: if element has a link assume it's a label, otherwise it's a parent.

[shiftkey]

Don't we just JSONify the YML?

I'm pretty sure we do when we generate the site.

Making the JS that consumes it robust against both structures would not be difficult: if element has a link assume it's a label, otherwise it's a parent.

👍

[adamralph]

So long as you're happy to special case a child named link. I.e. no project can be called 'link'.

[shiftkey]

For reference, this cool trick was raised in #310:

https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Aconfig-r+label%3Aup-for-grabs

Given your examples above mention the config-r account, perhaps this might be a good workaround until we work out how we want to manage labels? It's also kinda orthogonal to the multiple labels issue (as providing multiple labels here is an AND operation, rather than an OR) and totally complicates the work I was hoping to do with the API

[adamralph]

@shiftkey yep, that's a good trick.

In fact, @andreasohlund came up with the same idea for the Particular repos - https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3AParticular+label%3A%22Tag%3A+Up+For+Grabs%22 - and we're planning to send a PR (which I'll probably do tomorrow) to convert our "NServiceBus" listing to a "NServiceBus and the Particular Software Platform" listing.

Given this solution, I'm not sure this issue adds any value for me any longer. I can do the same with ConfigR and other orgs.

[shiftkey]

@adamralph I'm glad to know that works for you, but it kinda messes with my API ideas (and I think will break the issue counts currently displayed on the site).

As a way out of this, I've also been thinking around separating "links" - the stuff the user navigates to on the site - from more structured data which is available using the GitHub API.

For example, you could use the GitHub API to get all interesting issues for the Particular organization:

GET /orgs/Particular/issues?label="Tag%3A+Up+For+Grabs"

I'm happy to see your PR come in to use that different URL, and some time next week when I'm properly back at work I'll open up a discussion about extending the project structure to tackle some of these longer-term things...

[adamralph]

@shiftkey one problem that immediately jumps out is that not all projects are on GitHub...

[shiftkey]

@adamralph yes. I've been inferring from the issue link where the project is hosted, and I already exclude 6 projects (out of 180ish) from my naive implementation of calculating the issue count in bulk - because I can then hit the GitHub API directly with the right parameters.

That's not to say I can't/won't support other providers, but for now there's a bunch of data sitting there that we could leverage for fun on the site...

[daveaglick]

Here's a thought...

It seems reasonable that multiple repos for a given project may need different tags. I.e., one project has a low-level C hardware interface in one repo and a .NET GUI in another. That would yield a very different set of tags, may have different up for grabs labels, probably has a different description, etc.

Instead of addressing this by adding child elements, why not add an optional top-level element to represent that a given project .yml file should be grouped with other ones? I.e.:

config-r.yml

name: ConfigR
group: ConfigR
desc: Write your .NET configuration files in C#.
site: https://github.com/config-r/config-r
tags:
- configuration
- roslyn
- csx
- script
- scriptcs
- C#
upforgrabs:
  name: up-for-grabs
  link: https://github.com/config-r/config-r/labels/up-for-grabs

config-r-samples.yml

name: ConfigR Samples
group: ConfigR
desc: Samples for the ConfigR library.
site: https://github.com/config-r/config-r-samples
tags:
- configuration
- roslyn
- csx
- script
- scriptcs
- C#
- samples
upforgrabs:
  name: up-for-grabs
  link: https://github.com/config-r/config-r-samples/labels/up-for-grabs

Then in the GUI you could do some things with the new group element to visually distinguish them:

[adamralph]

@shiftkey fair enough, if you're covering 97% of projects then full steam ahead 🚢

@daveaglick not a bad take on the problem, and fully backwards compatible...

[shiftkey]

@daveaglick interesting idea 👍 will ponder on it further.

I'll leave it up to others here if they have other ideas for doing grouping in the UI.