Organizing GitHub Issues

[nathany]

Right now we have two sets of issues:

• https://github.com/gittip/shields.io/issues
• https://github.com/gittip/img.shields.io/issues

Do we want to try to have one repo with all the issues (using labels) or try to split them up to where the development is happening? (and use Contributing for guidance)

• The web site
• The img server / API
  • The image generation library
• The backend/analytics view (later)

Beyond that, I'd like to see some Milestones.

[chadwhitacre]

@nathany Thanks for stepping forward to lead this. We had one issue tracker at first and it didn't feel like a slam dunk. Issues and code go together and it's awkward to cross-link across repos. If you feel strongly I'm up for one issue tracker but I'm satisfied with the current two-issue-tracker setup.

[nathany]

It's things like #80 and badges/buckler#24 that get me asking this. It feels like the issue of Retina/SVG really belongs over where image generation is happening, and a PR should eventually close that issue in that repo. So if we have issues in two places, I'd be inclined to migrate some over there and close them here, as well as update the contributing to ask that people look at the appropriate place.

Alternatively...

Using project pages so that there only is one repo could work really well (at least right now). For end users, it probably makes more sense if there's just one place to report issues. At least, in my personal experience, I've been unsure of where to submit an issue to rspec whereas rails makes it obvious.

[chadwhitacre]

I could definitely see closing #80 in favor of badges/buckler#24. Since the web pages on http://shields.io/ basically don't exist right now we haven't had a clear sense of what belongs in this repo and what in that one (img.shields.io). I think as the over Shields project gains momentum the distinction will become more obvious, at least to those of us working on it. I expect we'll have to curate tickets from new contributors, moving them to the appropriate repo (similar to closing dupes).

[chadwhitacre]

Just checked the rspec example. That's rather extreme: 12 repos prefixed with rspec-! Over at #91 (comment) I'm suggesting three for our case. :-P

[nathany]

I'd be onboard for multiple repos, though I'd probably do it slightly differently than #91 (comment).

1. buckler. I think the majority of the code at img.shields.io is the buckler library + CLI, which means renaming that and organizing it further (@sqs started down this path). It becomes the library that shields.io depends on, in addition to http://buckler.repl.ca/ depending on it (since people are using it as an API). Anything related to colours, badge fonts, retina, SVG goes there.
2. shields.io (this repo) for both the (static) web site and the new body of code for the API. It relies on the buckler library to do the heavy lifting, but all the API and webhook-stuff, analytics, whatever else that is specifically shields goes here. At least to start, we can split out things later if necessary.

One thing I'm not certain about is if anyone is using what is now at https://github.com/gittip/img.shields.io-old outside of gittip.com?

Speaking as the newb on the project, what I'd hope for an initial milestone is something like:

1. @jbowes Able to deploy http://buckler.repl.ca based on the buckler library
2. @olivierlacan to verify colours and what-not regarding the PNG output of the buckler library

Followed by:

1. Able to offer the equivalent offline image generation at shields.io, and thereby encourage buckler users to switch
2. Some way of doing the dynamic generation for gittip at least (maybe even a temporary hack?)
3. Copy for the web site, including a blog post outlining plans/direction

Then getting to web hooks immediately after.

Hopefully different people can lead different parts, so someone can take on this API design stuff while other people are sorting out SVG/Retina on the library side.

[chadwhitacre]

One thing I'm not certain about is if anyone is using what is now at https://github.com/gittip/img.shields.io-old outside of gittip.com?

I wouldn't worry about this case. It only has one fork, which indicates that it is not heavily used.

[chadwhitacre]

Okay, I've done the following:

• renamed img.shields.io to buckler
• renamed shields.io to shields
• cleared out shields/master except for README, LICENSE, and CONTRIBUTING
• moved the static stuff to shields/gh-pages

Is that sufficient to close this ticket?

[nathany]

This just got more interesting.

It looks like most the action will be around the code at https://github.com/espadrine/gh-badges (and possibly https://github.com/cainus/shielded), while this repo is more focused on the website.

We still have buckler there if memory efficiency becomes an issue, though I'm sure a Node.js solution will serve us well if we're careful in how we implement it.

Time to tend the garden and cull these issues?

[nathany]

I did what I reasonably could to clean up the issues and setup milestones here. We should be in pretty good shape.

I'm gonna go ahead and close this for now.