The Team

[nathany]

It's great to see the implementations come together. Now let's formalize the core team.

For each area, I'd like to know who is willing to commit time, and one person to be responsible for ensuring stuff gets done (team lead).

Here are the areas I can think of:

• gh-badges implementation (Node.js). We'll set up a GitHub team for those who commit to contributing, doing code reviews, etc.
• Badge visual design spec
• web API design spec (including researching existing APIs and public facing documentation) web API design #100
• Web site content, including history, mission, etc.
• Web site and logo design
• Hosting/Devops
• Business administration
• Static SVG cross-browser testing (Retina)
• Srcset cross-browser testing @2x.png (Retina)

So step up or nominate someone. Use this thread to invite others to the project.

[nathany]

@Mikulas Thanks again for letting us use your organization. How would you like to be involved in the project going forward?

[nathany]

Guess I'll go first. In addition to the work I've been to help get us organized and on track, I commit to:

• Write the Shields section for the Monday Morning Missive.
• Maintain the Go implementation, at least until Shields.io officially launches. The Buckler library is being used by SourceGraph (ref). CocoaPods Badges and PyPI Shields/Pins (ref) are using its API (and I'm sure others I'm unaware of). Afaik @jbowes is the only one able to actually deploy it atm.
• Perhaps other research/writing if time allows.

[sqs]

Is 'API Design Spec' the design of the HTTP API, or the underlying node.js library? (Assuming the former.)

[nathany]

@sqs I intended the former. Here's an issue to discuss it further. #100

[Mikulas]

@nathany While I understand why you've chosen to start working from gh-badges, it just seems to me you are arriving at the same problems I already solved in my implementation. That's no jealousy speaking or whatever, it just seems wasteful. My opinion notwithstanding, I will continue researching the optimal method for loading embedded fonts in svg, possibly with font subsetting if I find no magical all-browser-supported hack so your current svg template can benefit from it while retaining the (uneccessary) small file size.

[espadrine]

@Mikulas That's really great!

I'd love you to document your findings. If you find a better tradeoff than what gh-badges has to offer, it can probably benefit from it as well.

Currently, the big issue is loading. I'd assume it may be possible to have a fast-track loading for ASCII only, and a (or multiple wrt regionalization) slow-track(s) for unicode characters.

Btw, you only need to include one font — I noticed you include several. Having a local("Open Sans") is equally meaningless, since the base64 TTF would work everywhere..

[Mikulas]

@espadrine I include one font, but in two different formats for compatibility. One works in mobile Safari and the other is for early firefox if I recall correctly - including only one breaks the other. Will document this later on. local("Open Sans") is there because I believe it could be faster for the browser to address a font it could have in memory then parsing the base64 encoded file. It depends on the actual css parser implementation, I should probably benchmark it. But hey, it's just a few bytes anyway :)

Also what http://caniuse.com/ttf is about is including the font in a website. Including the font in a svg is major problem and it's not supported well in most browsers. Base64 encoded truetype does NOT work in SVG in all browsers. I will create samples and shots from browserstack.com soon for you guys to check and for future reference.

PS: browsers render raw svg differently than embedded svg inside a web page (ig example.com/test.svg vs example.com that has test.svg in an image tag). Firefox loads the font on one but not the other etc.

[nathany]

Thanks @Mikulas.

While I appreciate the enthusiasm, let's try to keep this thread to a discussion of what people are committing to, and discussion about the font in #97. Think of your future self when trying to scan through what was said. Cool?

[nathany]

While I understand why you've chosen to start working from gh-badges, it just seems to me you are arriving at the same problems I already solved in my implementation. That's no jealousy speaking or whatever, it just seems wasteful. - #96 (comment)

I don't consider rewriting an implementation wasteful, especially at this early state:

In most [software] projects, the first system is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved.... Hence, plan to throw one away; you will, anyhow. - Fred Brooks

What's important to me is that we have the team of people that built these implementations and the _enthusiasm_ to continue building a production-ready version. Consider the font research #97 (comment) you've done. I'm sure that took a fair bit of time, but to take that and apply it to another implementation is now just a few lines of code.

That said, if people would like to do a more formal evaluation of the existing implementations, I'll create a new issue with some criteria to get us started. @Mikulas Fyi, I didn't see the PHP/server code in your repo.

[chadwhitacre]

@nathany I'm willing to work on:

• Web site content, including history, mission, etc.
• Business administration

I'll help with Hosting/DevOps as I'm needed for that. Ideally we can hand that off to others once a few things stabilize (SSL, GH pages, ...).

I'm also closely watching the branding/logo ticket (#92). I'm watching the rest of the tickets, too. :-)

[seanlinsley]

I'd usually sign up for Hosting/Devops since it's "easy" for me, but I'd be willing to take on whatever no one else will.

[nathany]

@seanlinsley That'd be great. Dev Ops is not my cup of tea.