other issue data here or elsewhere?

[jbenet]

Do you want to use this module to grab other issue data? (status, labels, assignee, etc) Or should this be a separate module?

I would imagine this one to save on requests, but then again, we could use a proxy in between that caches requests or something. so yeah, prob separate, but figured i'd ask.

[hackergrrl]

I've been thinking about this, and the more ugly GitHub API code I write the more I want to break apart the pieces. I'm thinking we split the module in two:

1. github-issues-fetch: given a GitHub org, repo, or issue, returns those raw issues. Takes care of pagination at the org and issue level.
2. github-dependency-crawl: given the output of (1), pulls out the "Depends on ..." content and recursively grabs external dependencies (also using (1)) until all are resolved. Returns the dependency tree that you see today, except with raw issue data attached.

This makes the whole process much more like a stateless pipeline:

fetch-issues ----> issues-to-dep-graph ---> post-processors

Where "post-processors" might be things like "look at the graph and apply color values to issues depending on their open/closed/ready-to-work-on status". Your dot renderer would be the final sink in that pipeline.

This also means the fetch-issues source can more easily be IPFS or local FS or the Github API.

[jbenet]

This sounds great to me.
On Wed, Aug 17, 2016 at 19:06 Stephen Whitmore [email protected]
wrote:

I've been thinking about this, and the more ugly GitHub API code I write
the more I want to break apart the pieces. I'm thinking we split the module
in two:

1. github-issues-fetch: given a GitHub org, repo, or issue, returns
   those raw issues. Takes care of pagination at the org and issue level.
2. github-dependency-crawl: given the output of (1), pulls out the
   "Depends on ..." content and recursively grabs external dependencies (also
   using (1)) until all are resolved. Returns the dependency tree that you see
   today, except with raw issue data attached.

This makes the whole process much more like a stateless pipeline:

fetch-issues ----> issues-2-dep-graph ---> post-processors

Where "post-processors" might be things like "look at the graph and apply
color values to issues depending on their open/closed/ready-to-work-on
status". Your dot renderer would be the final sink in that pipeline.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#13 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIcoR3jmyDsojfdzkM-C7T9IQtJuwvLks5qg5P-gaJpZM4JmTVS
.