Mailman 3 September 2016 - scikit-image

how to find the intersection point of two objects
by LC 15 Sep '16

15 Sep '16

Dear All, I am new to image processing and using OpenCV on python for implementing a part of research work. The aim is : - To identify the predecessor and successor of an object (shape) and - To calculate the Indegree(edges coming on shape) and outdegree(edges going out from shape) of object. Or is thr anyway to find digraph for given image? Can anybody help to find the intersection point of two object called rectangle and edges(directed line) in the attached img? your guidance /pointers will be appriciated. thanks & regards

1 0

Re: Management of PRs, issues, and threads
by Stefan van der Walt 15 Sep '16

15 Sep '16

On Sun, Sep 11, 2016, at 23:13, Juan Nunez-Iglesias wrote: > > This way your PRs are always checked against the latest master, not > > whatever was around when they were first made > > I thought Travis did this already? > > https://docs.travis-ci.com/user/pull-requests > > "Rather than test the commits that have been pushed to the branch the > pull request is from, we test the merge between the origin and the > upstream branch." This happens the moment you make the PR, or push new commits. Ideally, you want to run the tests just before merging. Stéfan

1 0

Task board
by Stefan van der Walt 15 Sep '16

15 Sep '16

Hi, everyone As Juan mentioned recently, it's becoming harder to keep track of the motion of the project as a whole. Sometimes, tickets lounge unattended for an unacceptable long time. I can think of two main routes for improving the situation: 1) Improve our team structure, so that individuals take responsibility for moving certain aspects of the project forward. 2) Processes / systems to help us get a grasp on the current state of things I have some ideas around (1) that need fleshing out, but in the mean time I was looking at http://zube.io to address part of (2). Do you have any experience with this system? Zube can be compared against HuBoard, gh-board, and ZenHub. A test scikit-image board is here: https://zube.io/projects/4670/kanban (it's vanilla, I haven't done anything with it yet) Let me hear your thoughts. Stéfan

3 5

Re: Management of PRs, issues, and threads
by Johannes Schönberger 15 Sep '16

15 Sep '16

This should very be interesting in this regard: https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-too… > On 12 Sep 2016, at 18:35, Nelle Varoquaux <nelle.varoquaux(a)gmail.com> wrote: > > Hi scikit-image folks! > > >> We've had a couple of community fails on GitHub recently: >> https://github.com/scikit-image/scikit-image/pull/1474#issuecomment-2412830… >> https://github.com/scikit-image/scikit-image/issues/2080 >> (The last one is missing a presumably-deleted comment where someone outside >> the project recommended to a potential contributor to just fork the >> project!). > > Being the person that reported one of those community fails, I'd like > to say that I've had great experience with the scikit-image community > overall. Contributors are (usually) very well welcomed, feedback is > friendly, and we can have discussion and debates about "hot" topics > (like dropping python2.7) in a friendly and nice environment. I've > recently contributed to another scientific python project where many > members of the community were aggressive in their reviews, without > giving valuable feedback on PRs, so I value scikit-image's (& > scikit-learn) community even more. > >> That's just the couple I've noticed, I'm sure there are lots more. We >> definitely have many, many abandoned PRs from >1y, >2y ago. >> >> Obviously, something in our process isn't working. I don't have immediate >> solutions, but here's a couple of suggestions: >> >> - we need a system to assign core devs to PRs/issues. Currently, it's too >> easy for all of us to go, "someone else on the team will handle this". We >> need a fair way to assign a manager to each issue/PR. The assigned dev >> wouldn't necessarily be responsible for review, but they would be >> responsible for chasing up other reviewers. >> >> - NEVER close a PR without the explicit consent of the contributor, OR after >> the contributor has been non-responsive for e.g. 1mo and two pings. In this >> last situation I would even suggest that we need two core devs to sign off. > > I would not close old PR, for the sake of closing them. If the > contributor is not interested in finishing the contribution and the > patch is almost ready, it might be a good way to introduce new > contributors (/students) to the PR. This can probably be done by an > "Need contributor" tag + "Easy fix", though I haven't thought more > about this > >> Other suggestions welcome in this thread. We should try to get a new process >> hammered out very soon. >> >> I also want to acknowledge @soupault for his triage/labelling work, which is >> a massive step in the right direction. But we need to follow up his triage >> with some actual process. >> >> Juan. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image+unsubscribe(a)googlegroups.com. >> To post to this group, send email to scikit-image(a)googlegroups.com. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/scikit-image/CA%2BJHcKSh-k%2ByM0yBTRzTy%3…. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > To post to this group, send an email to scikit-image(a)googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAE-UAvSnKid2zn9bM4%3DdU2mvG…. > For more options, visit https://groups.google.com/d/optout.

1 0

Re: Management of PRs, issues, and threads
by Nelle Varoquaux 13 Sep '16

13 Sep '16

Hi scikit-image folks! > We've had a couple of community fails on GitHub recently: > https://github.com/scikit-image/scikit-image/pull/1474#issuecomment-2412830… > https://github.com/scikit-image/scikit-image/issues/2080 > (The last one is missing a presumably-deleted comment where someone outside > the project recommended to a potential contributor to just fork the > project!). Being the person that reported one of those community fails, I'd like to say that I've had great experience with the scikit-image community overall. Contributors are (usually) very well welcomed, feedback is friendly, and we can have discussion and debates about "hot" topics (like dropping python2.7) in a friendly and nice environment. I've recently contributed to another scientific python project where many members of the community were aggressive in their reviews, without giving valuable feedback on PRs, so I value scikit-image's (& scikit-learn) community even more. > That's just the couple I've noticed, I'm sure there are lots more. We > definitely have many, many abandoned PRs from >1y, >2y ago. > > Obviously, something in our process isn't working. I don't have immediate > solutions, but here's a couple of suggestions: > > - we need a system to assign core devs to PRs/issues. Currently, it's too > easy for all of us to go, "someone else on the team will handle this". We > need a fair way to assign a manager to each issue/PR. The assigned dev > wouldn't necessarily be responsible for review, but they would be > responsible for chasing up other reviewers. > > - NEVER close a PR without the explicit consent of the contributor, OR after > the contributor has been non-responsive for e.g. 1mo and two pings. In this > last situation I would even suggest that we need two core devs to sign off. I would not close old PR, for the sake of closing them. If the contributor is not interested in finishing the contribution and the patch is almost ready, it might be a good way to introduce new contributors (/students) to the PR. This can probably be done by an "Need contributor" tag + "Easy fix", though I haven't thought more about this > Other suggestions welcome in this thread. We should try to get a new process > hammered out very soon. > > I also want to acknowledge @soupault for his triage/labelling work, which is > a massive step in the right direction. But we need to follow up his triage > with some actual process. > > Juan. > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > To post to this group, send email to scikit-image(a)googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/scikit-image/CA%2BJHcKSh-k%2ByM0yBTRzTy%3…. > For more options, visit https://groups.google.com/d/optout.

1 0

Re: Management of PRs, issues, and threads
by Juan Nunez-Iglesias 12 Sep '16

12 Sep '16

> This way your PRs are always checked against the latest master, not whatever was around when they were first made I thought Travis did this already? https://docs.travis-ci.com/user/pull-requests "Rather than test the commits that have been pushed to the branch the pull request is from, we test the merge between the origin and the upstream branch." However this would imply that Travis wouldn't do anything when you can't automatically merge. I don't remember whether this is True... On 10 September 2016 at 5:33:04 PM, Matthew Brett (matthew.brett(a)gmail.com) wrote: Hi, On Sat, Sep 10, 2016 at 12:21 AM, Stefan van der Walt <stefanv(a)berkeley.edu> wrote: > On Thu, Sep 8, 2016, at 07:22, Egor Panfilov wrote: > > Remember me hyping around with the GitHub bot idea? > Here it is: > - in the source code: https://github.com/facebook/mention-bot > - in action: > https://github.com/tensorflow/tensorflow/pull/4239#issuecomment-245180925 > > > This is cute. Although I think what could be even more useful is a feature > I saw elsewhere: instead of clicking the merge button, you instruct it to > re-run the test suite and merge upon successful completion. This way your > PRs are always checked against latest master, not whatever was around when > they were first made. Yes, this was the homu bot - we have a copy of that running on the nipy server in Berkeley. Matthias B of IPython fame was talking about sharing some work to refactor the homu code into something more general to extend the range of github tasks it could do - maybe including mention-automation like the face-book-bot. Matthew -- You received this message because you are subscribed to the Google Groups "scikit-image" group. To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. To post to this group, send an email to scikit-image(a)googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAH6Pt5phve%3DS1t1haAVT%3D3%…. For more options, visit https://groups.google.com/d/optout.

1 0

Re: Management of PRs, issues, and threads
by Egor Panfilov 10 Sep '16

10 Sep '16

Dears, I believe there might be a generic solution already: see my comment ( https://github.com/scikit-image/scikit-image/issues/2269#issuecomment-24335…) and, particularly, "rust-lang" reference. Regards, Egor 2016-09-10 10:32 GMT+03:00 Matthew Brett <matthew.brett(a)gmail.com>: > Hi, > > On Sat, Sep 10, 2016 at 12:21 AM, Stefan van der Walt > <stefanv(a)berkeley.edu> wrote: > > On Thu, Sep 8, 2016, at 07:22, Egor Panfilov wrote: > > > > Remember me hyping around with the GitHub bot idea? > > Here it is: > > - in the source code: https://github.com/facebook/mention-bot > > - in action: > > https://github.com/tensorflow/tensorflow/pull/4239# > issuecomment-245180925 > > > > > > This is cute. Although I think what could be even more useful is a > feature > > I saw elsewhere: instead of clicking the merge button, you instruct it to > > re-run the test suite and merge upon successful completion. This way > your > > PRs are always checked against latest master, not whatever was around > when > > they were first made. > > Yes, this was the homu bot - we have a copy of that running on the > nipy server in Berkeley. Matthias B of IPython fame was talking > about sharing some work to refactor the homu code into something more > general to extend the range of github tasks it could do - maybe > including mention-automation like the face-book-bot. > > Matthew > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > To post to this group, send an email to scikit-image(a)googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/ > msgid/scikit-image/CAH6Pt5phve%3DS1t1haAVT%3D3% > 3DRhwwDBdZzO9Mqh1ED4_cDx2B-Pw%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. >

1 0

Re: Management of PRs, issues, and threads
by Matthew Brett 10 Sep '16

10 Sep '16

Hi, On Sat, Sep 10, 2016 at 12:21 AM, Stefan van der Walt <stefanv(a)berkeley.edu> wrote: > On Thu, Sep 8, 2016, at 07:22, Egor Panfilov wrote: > > Remember me hyping around with the GitHub bot idea? > Here it is: > - in the source code: https://github.com/facebook/mention-bot > - in action: > https://github.com/tensorflow/tensorflow/pull/4239#issuecomment-245180925 > > > This is cute. Although I think what could be even more useful is a feature > I saw elsewhere: instead of clicking the merge button, you instruct it to > re-run the test suite and merge upon successful completion. This way your > PRs are always checked against latest master, not whatever was around when > they were first made. Yes, this was the homu bot - we have a copy of that running on the nipy server in Berkeley. Matthias B of IPython fame was talking about sharing some work to refactor the homu code into something more general to extend the range of github tasks it could do - maybe including mention-automation like the face-book-bot. Matthew

1 0

Re: Management of PRs, issues, and threads
by Emmanuelle Gouillart 10 Sep '16

10 Sep '16

Hi Juan, thanks for bringing these issues to light. How about we tackle the queue of open PRs from its two ends? That is, for the new PRs we have this manager system (we still need to decide how to assign them), and at the same time we go through old PRs to try to unblock or (worst case) close them? Best, Emma On Mon, Aug 22, 2016 at 02:47:16PM +1000, Juan Nunez-Iglesias wrote: > Hi everyone, > We've had a couple of community fails on GitHub recently: > https://github.com/scikit-image/scikit-image/pull/1474#issuecomment-2412830… > https://github.com/scikit-image/scikit-image/issues/2080 > (The last one is missing a presumably-deleted comment where someone outside the > project recommended to a potential contributor to just fork the project!). > That's just the couple I've noticed, I'm sure there are lots more. We > definitely have many, many abandoned PRs from >1y, >2y ago. > Obviously, something in our process isn't working. I don't have immediate > solutions, but here's a couple of suggestions: > - we need a system to assign core devs to PRs/issues. Currently, it's too easy > for all of us to go, "someone else on the team will handle this". We need a > fair way to assign a manager to each issue/PR. The assigned dev wouldn't > necessarily be responsible for review, but they would be responsible for > chasing up other reviewers. > - NEVER close a PR without the explicit consent of the contributor, OR after > the contributor has been non-responsive for e.g. 1mo and two pings. In this > last situation I would even suggest that we need two core devs to sign off. > Other suggestions welcome in this thread. We should try to get a new process > hammered out very soon. > I also want to acknowledge @soupault for his triage/labelling work, which is a > massive step in the right direction. But we need to follow up his triage with > some actual process. > Juan.

3 2

Re: Task board
by Ralf Gommers 06 Sep '16

06 Sep '16

On Mon, Sep 5, 2016 at 10:42 PM, Stefan van der Walt <stefanv(a)berkeley.edu> wrote: > On Sun, Sep 4, 2016, at 01:32, Egor Panfilov wrote: > > You mean RFCs like PEPs? > > > Exactly. I think, this format would help to accumulate our opinions on > different matters (e.g. how to we treat and depend on `matplotlib`) > > > We should chat to Ralf Gommers to find out how successful the Enhancement > Proposal approach has been for SciPy, which is similar to this project in > many ways. > Since we don't have those for SciPy, I'd say not very:) You're thinking about NumPy probably: http://docs.scipy.org/doc/numpy/neps/index.html https://github.com/numpy/numpy/tree/master/doc/neps We don't use them often, but when we do they've been valuable. For example the .npy version format is a good reference with rationale, and for complex discussions like datetime and NA it helps to summarize the issues and outlike solution directions (emails really don't work well for that). Cheers, Ralf

1 0