Open jbenet opened 7 years ago
Sounds really useful, especially with a webapp: dependency graph could be embedded via ![](https://webapp/ghuser/project/deps.png)
(just like CI badges are).
Oh yeah, great idea! On Thu, Aug 4, 2016 at 04:15 Marcin Rataj notifications@github.com wrote:
Sounds really useful, especially with public webapp: dependency graph could be embedded via (just like CI badges are).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jbenet/random-ideas/issues/37#issuecomment-237484572, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIcocJNd8ZWowBiq5XV3_rcdAERSkWoks5qcZ-zgaJpZM4JcSnd .
Relationships:
Depends on
denotes a "dependency", an issue that MUST be finished before this one can finish.Contains
denotes a "sub-issue", something that's not just a dependency, it's "part of" this issue.Could use checkboxes to show when they're done. Would prob involve manual overhead though, unless we wanted to do a lot of scripting...
# example with checkboxes:
- [ ] Depends on: <link-to-issue>
- [ ] Contains: <link-to-issue>
I'm actively looking for someone to make this for me, could pay you for it -- I would really benefit from this and dont have the bw to make it atm.
Hey @jbenet :wave:
I really like the idea, and would also like to see this happen. I spent some time today writing https://github.com/noffle/github-dependency-crawl. It crawls a github repo recursively for issue dependencies, and spits out the dependency graph. Its pretty pluggable too (you don't even need to use github as the data source, so you could e.g. pull issue data from IPFS). I'm actually using it to manage its own dependencies :grinning: https://github.com/noffle/github-dependency-crawl/issues/7
@noffle :wave: very nice! thanks for making that, it's is a great start. 👍 🎉
you don't even need to use github as the data source, so you could e.g. pull issue data from IPFS
may want to keep the full URL of the issue then? looks like right now it removes github.com/
and issues/
which may not be desired if issues are pulled from elsewhere? (not sure)
graphviz on the web:
(3 years ago i really wanted these and they didnt exist. very happy they do now)
other libs:
not related, but this is pretty cool:
This seems to be the trac plugin's code:
may want to keep the full URL of the issue then? looks like right now it removes github.com/ and issues/ which may not be desired if issues are pulled from elsewhere? (not sure)
Without getting into detail here, the canonical string should be sufficient to let you deduce the source URL from the data source of choice (owner/repo/issue has a well-documented mapping to an API endpoint, and if it's on IPFS that mapping should also be well-documented, e.g. /ipfs/HASH/gh/owner/repo/issue).
I took a stab at the dot generation. this is a super basic version: https://github.com/jbenet/issue-dep-graph
> issue-dep-dot https://github.com/noffle/github-dependency-crawl
digraph deps {
noffle_github_dependency_crawl_12 [label="noffle/github-dependency-crawl/12"];
noffle_github_dependency_crawl_11 [label="noffle/github-dependency-crawl/11"];
noffle_github_dependency_crawl_10 [label="noffle/github-dependency-crawl/10"];
noffle_github_dependency_crawl_9 [label="noffle/github-dependency-crawl/9"];
noffle_github_dependency_crawl_8 [label="noffle/github-dependency-crawl/8"];
noffle_github_dependency_crawl_7 [label="noffle/github-dependency-crawl/7"];
noffle_github_dependency_crawl_4 [label="noffle/github-dependency-crawl/4"];
noffle_github_dependency_crawl_5 [label="noffle/github-dependency-crawl/5"];
noffle_github_dependency_crawl_6 [label="noffle/github-dependency-crawl/6"];
noffle_github_dependency_crawl_3 [label="noffle/github-dependency-crawl/3"];
noffle_ipget_18 [label="noffle/ipget/18"];
noffle_github_dependency_crawl_2 [label="noffle/github-dependency-crawl/2"];
noffle_github_dependency_crawl_1 [label="noffle/github-dependency-crawl/1"];
ipfs_ipget_24 [label="ipfs/ipget/24"];
ipfs_ipget_26 [label="ipfs/ipget/26"];
ipfs_ipget_20 [label="ipfs/ipget/20"];
ipfs_ipget_21 [label="ipfs/ipget/21"];
noffle_github_dependency_crawl_7 -> noffle_github_dependency_crawl_4;
noffle_github_dependency_crawl_7 -> noffle_github_dependency_crawl_5;
noffle_github_dependency_crawl_7 -> noffle_github_dependency_crawl_6;
noffle_github_dependency_crawl_3 -> noffle_ipget_18;
noffle_github_dependency_crawl_2 -> noffle_github_dependency_crawl_3;
noffle_github_dependency_crawl_1 -> noffle_github_dependency_crawl_2;
noffle_github_dependency_crawl_1 -> noffle_github_dependency_crawl_3;
noffle_ipget_18 -> ipfs_ipget_24;
noffle_ipget_18 -> ipfs_ipget_26;
noffle_ipget_18 -> ipfs_ipget_20;
noffle_ipget_18 -> ipfs_ipget_21;
}
Is gantt charts something like this(http://dhtmlx.com/docs/products/dhtmlxGantt/01_basic.html)?
@zjiekai yeah! I'd like to generate them from github issues that have some dependency (and "containing") structure.
It's hard to figure out the time it will take, but even charting out the dependenceis, some basic assumptions (like N hrs per issue) may generate a really good perspective, and logging the past accurately would be super helpful.
"containing issues" means one issue "contains" another (more than a simple dependency, it's treating an issue like a bundle of other issues (milestones or epics). GH Milestones don't fit all needs because GH Milestones are per repo and not across repos. (some prefer milestones backed by an issue)
More on graphviz:
@jbenet Hi, I have a tiny demo here(https://zjiekai.github.io/issue-dep-graph/). I'm not sure about how to set the start of an issue. Ideally it may look like this:
Do you prefer using the dot graph?
@noffle I'm not sure how to get the issue data. So I'm using this hack(https://github.com/zjiekai/github-dependency-crawl/commit/e7a7b1783a472606fd9cca8b290d29dd104b5853) for now.
Update: @jbenet I just saw your above comment. Personally I find the graphviz layout to be more pleasing than gantt chart. I'm wondering why not use graphviz directly once but having every web view running the js version in a web worker?
@zjiekai The API doesn't expose raw issue data yet. Coming Soon(tm): https://github.com/noffle/github-dependency-crawl/issues/13
@zjiekai
Hi, @jbenet In the demo, I'm using the open time as the start and a 7-day duration.
reminds me of https://en.wikipedia.org/wiki/Precedence_diagram_method
@zjiekai
- an issue can be opened before its dependents, but can only be started after its dependents are finished?
well not strictly. gantt charts try to forecast project durations based on strict pre-reqs. maybe some would argue an issue should be split in two (the part than can be started before-pre-req, and the part that hard-requires the pre-req). It's a tough call, it depends on what the utility is supposed to be. Maybe the chart could show a faded background color from "open date" to "close date", and a darker color from "all pre-reqs closed date" and "close date". or something.
- If there are no careful restrictions the gantt charts can be rather messy.
yeah not very useful.
cc @jesseclay
I'd worry less about the charts per se than simply about allowing users to edit the information sanely.
In particular, if you're discussing github issues, then an arrow might just be someone's opinion that resolving an issue in necessary for some other issue. If however either issue got resolved somewhat differently, then that arrow might not make sense.
Arrow existence and direction still remains more relevant than just an internal github backwards link though because it'll help people understand the discussion faster. And help newbies pick issues to work on.
@burdges yeah makes sense. i think the flexibility we have with marking depends on X
in an issue is enough here-- people will be able to decide on that. Toggling modes so that only markings in the initial issue comment counts (i.e. must have edit perms) can strike the right balance for what a project's thoughts are on what counts as a dependency (whether to be strict, or loose)
Quick update here: the excellent @wking and I have been making some headway and progress in the implementaiton of depviz (impl all by wking). Follow the progress: https://github.com/jbenet/depviz or try it out: https://jbenet.github.io/depviz
examples:
HI, I have a question. When you use viz.js, the node in viz is svg, but deps node here is very complex(like embeded html) and interactive(embeded buttons...), how your guys solve this issue?
On Tue, Dec 27, 2016 at 05:31:39AM -0800, Sparks 范宜臻 wrote:
… the node in viz is svg, but deps node here is very complex(like embeded html) and interactive(embeded buttons...), how your guys solve this issue?
The nodes are rectangular, so all depviz uses viz.js for positioning rectangular nodes (and eventually for routing edges between them, jbenet/depviz#24). The graph-positioning engine doesn't have to care about who's drawing the node content. depviz currently uses SVG node content as well (which supports embedded buttons, etc.), but if you wanted you could use foreignObject and HTML inside the nodes 1.
thanks~ I understand what you mean. @wking
Something new from GH: https://github.com/blog/2300-visualize-your-project-s-community
On Thu, Jan 05, 2017 at 08:36:50AM -0800, Manfred Touron wrote:
Something new from GH: https://github.com/blog/2300-visualize-your-project-s-community
That is for dependencies between projects. This issue and depviz are for dependencies between issues. The latter are likely to be a more-specific version of the former (e.g. “graphql-parallel depends on graphql-ruby” is a project-level dependency and “graphql-parallel#123 depends on graphql-ruby#456” is an issue-level dependency).
Adding Dependencies to Github Issues
This is an old idea, many people have had it. I'm just laying out here as a point for discussion, so that we can build it.
Desires
Proposal
1. Parse Dependencies from Comments
We can parse comments in an issue and detect text like:
To make the dependency graph explicit. Then we can create a tool (or a site like waffle.io) that crawls a repo's issues.
2. Put dependencies on ipfs
Take the crawled dependencies and put them on IPFS (dag base)
3. Generate visual graphs
Use tools like graphviz to visualize dependency graphs.
4. Webapp showing deps
We can make a webapp that shows dependency graphs for:
(Note that if we implement support based on running github searches, we get most of these for free.)
Other Considerations