I would really like to help "revamp" this project. That's why, I have spent some time trying to get myself familiar with the code and the documentation, and there is something about the following diagram that I don't quite understand:
In the top right corner of Issue #10 we can see a # 2 inside a red circle.
However, issue #10 seems to have 3 dependencies (it has 3 arrows pointing towards it). One of them (issue #3) is resolved. Is that the reason why the counter only displays 2?
Or is it perhaps because issue #3 is an "indirect" dependency? What I mean by indirect dependency is that issue #7 already has a dependency on issue #3 (and issue #10 depends on issue #7).
Since issue #7 already depends on issue #3, perhaps it would make sense not to count issue #3 as a direct dependency of #10, even if it was explicitly flagged as such. However, if that was the case, I think that it would be best not to draw the arrow that points from #3 to #10 (the less arrows, the easier it would be to visualize the diagram, I think).
Another question/opinion, about the colors of the circles in the corners: Lets say that an issue has 4 dependencies: 3 of them are resolved and 1 of them is unresolved. The top right circle should display red, correct? I am not sure about the number that it should display, though... Should it be 1 or 4? and if the answer is 1, I guess that number would become 4 (and the circle green) once that last dependency is resolved, right?
I think that perhaps it could be helpful to find a way to display both numbers when not all the dependencies are resolved/unresolved... Or maybe -using the values of the last example- show 3/4 of the filling in green and 1/4 of the filling in red, with the text 4 over the circle, and if the user clicks on the circle, "split" it in 2: one red and the other one green with their corresponding numbers... It is just a (crazy) idea.
Sorry if I'm reading too much into this, and sorry if I'm being too opinionated. It's just that I would like to make sure that I understand it well before I try to make any contributions.
Hi,
I would really like to help "revamp" this project. That's why, I have spent some time trying to get myself familiar with the code and the documentation, and there is something about the following diagram that I don't quite understand:
In the top right corner of Issue
#10we can see a # 2 inside a red circle.However, issue
#10seems to have 3 dependencies (it has 3 arrows pointing towards it). One of them (issue#3) is resolved. Is that the reason why the counter only displays 2?Or is it perhaps because issue
#3is an "indirect" dependency? What I mean by indirect dependency is that issue#7already has a dependency on issue#3(and issue#10depends on issue#7).Since issue
#7already depends on issue#3, perhaps it would make sense not to count issue#3as a direct dependency of#10, even if it was explicitly flagged as such. However, if that was the case, I think that it would be best not to draw the arrow that points from#3to#10(the less arrows, the easier it would be to visualize the diagram, I think).Another question/opinion, about the colors of the circles in the corners: Lets say that an issue has 4 dependencies: 3 of them are resolved and 1 of them is unresolved. The top right circle should display red, correct? I am not sure about the number that it should display, though... Should it be 1 or 4? and if the answer is 1, I guess that number would become 4 (and the circle green) once that last dependency is resolved, right?
I think that perhaps it could be helpful to find a way to display both numbers when not all the dependencies are resolved/unresolved... Or maybe -using the values of the last example- show 3/4 of the filling in green and 1/4 of the filling in red, with the text
4over the circle, and if the user clicks on the circle, "split" it in 2: one red and the other one green with their corresponding numbers... It is just a (crazy) idea.Sorry if I'm reading too much into this, and sorry if I'm being too opinionated. It's just that I would like to make sure that I understand it well before I try to make any contributions.
Thanks,
cc @jbenet @VictorBjelkholm