Closed adambraimbridge closed 5 years ago
I vote for option a, "Do nothing in Tako".
I think Tako should do one thing and do that one thing well: provide us with a list of the repositories that we own.
We talked about this in a meeting. It is counter to #102. We should avoid scope creep in Tako.
This request is only so Huston doesn't need to ask another API for more detailed information. Information about repositories is already available from the GitHub API.
Adam you thought that Houston would hit the GitHub rate limits. I pointed out that the requests Huston would spam GitHub with would only be pointing at Tako instead. That didn't seem like a good reason to surface this information in Tako.
Health
, see https://github.com/Financial-Times/next/issues/300.
Node
, this can be figured out from the package.json
when required.
Description
, available from the GitHub API.
Owner
, already surfaced by Tako.
URLs
, can be built using the name and owner of a repository.
So, option a
.
Option (a) it shall be, for very good reason: Just Say No to Scope Creep.
I predict that Financial-Times/next#300 will essentially be a clone of Tako with the additional fields included. Then I imagine the new Ombudsman will be used almost exclusively instead of Tako. I hope my prediction is wrong. But I also kinda hope future Adam can look back at this and say, "Aha! I knew it!" :)
With https://houston.ft.com/ombudsman as a use case, there are some properties that are arguably desirable, but not exposed in tako.
Name
Type
topics
)Health
Description
Owner
URLs
Node
(Version)Options
a) Do nothing in Tako (and make houston-api query GitHub or BizOps for the additional data)
b) Expose whichever of the above are available from the GitHub API (and currently filtered out)
c) Do (b), but require a flag to output the additional information (e.g.
--verbose
)