Yeah I was also thinking of a similar solution to cope this concern. Moreover, I was thinking if it is possible to develop some tool such that when some PR is merged fixing some specific issue, then we also try to run all the existing issues and see if some additional issues are also getting resolved. And if any additional issue gets resolved then we close that issue automatically referencing that PR.
This way the number of pending issues will decrease and will increase efficiency. On Tue, 4 Feb, 2020, 3:59 PM Gagandeep Singh (B17CS021), < [email protected]> wrote: > Yes, that's probably a concern. For that I would suggest you to first test > whether an issue persists in the latest version of the master branch. > Usually many old issues are fixed but are still open. One more thing you > can do is to create WIP PRs instead of showing diffs. Though do make sure > any active PR isn't working on an issue in which you are interested. In > this way, you can start initialising your work a bit before the formal > start of your project and your efforts will not go in vain. > In fact cherry picking commits from some stalled PRs would be great to > give credits to the original authors. > > > On Tue, Feb 4, 2020 at 3:54 PM Sachin Agarwal <[email protected]> > wrote: > >> Thanks Gagandeep for your valuable suggestion. I will start working on >> those issues marked as "Please Take Over" to get a head start. >> >> But I have one concern, suppose I am working on some issue on my local >> machine and thinking of including a fix for it in my proposal. But after >> the application period has ended, suppose someone solves that issue during >> April, then including that issue in my proposal would be a waste. >> >> >> >> On Tue, 4 Feb, 2020, 3:47 PM Gagandeep Singh (B17CS021), < >> [email protected]> wrote: >> >>> Hi Sachin, >>> >>> I think has Oscar has highlighted some very good points about your idea. >>> I would like to add a few points to it. >>> >>> Fixing issues in GSoC project is nice though quite unpredictable, for >>> example an issue in stats module can be linked to probably integrals or >>> solvers module. However, there is still some scope for making an organised >>> and well designed proposal. >>> You can start with first making draft list of issues on which you want >>> to work during the summers. You can include those issues which you think >>> you can fix, that is you should be confident enough after looking at the >>> example code and doing some background research on it. Then you can divide >>> the list into various modules. Though note that you should put an issue >>> under the module where the root cause of it lies and not where it was >>> reported. For example, most of the performance related problems in >>> computing CDF of a random variable are connected to the integrals module >>> though they are reported under the stats module. You can discuss on github >>> about where the root cause lies. Dividing the list into modules can be >>> helpful in allocating mentors. You can include some git diffs in your >>> proposal which will show your attempts at making those fixes, though it is >>> not expected from you to show fully working code. >>> >>> One more idea that you can include in the community bonding period, >>> which is to increase the code coverage by adding/improving tests. This will >>> also help you to identify new bugs which you can fix during the coding >>> period or may be it can also be helpful for some future student. The >>> current coverage is usually around 75% which should be increased. >>> >>> IMO, picking those issues which already have `Please take over` labelled >>> PRs will be a great step in continuing stalled work, and it will also >>> provide you a head start. >>> >>> >>> >>> On Tue, Feb 4, 2020 at 3:15 PM Oscar Benjamin < >>> [email protected]> wrote: >>> >>>> Hi Sachin, >>>> >>>> I think that a project along these lines needs to have some scope. >>>> There are a lot of open issues so which ones roughly would you fix? >>>> >>>> It needs to be possible for someone to act as a mentor so it should be >>>> well-defined which parts of the codebase you will work on. Issues on >>>> github are labelled so e.g. one possibility would be to say that you >>>> will focus on the concrete module and the issues that are labelled as >>>> concrete: >>>> >>>> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Aconcrete >>>> >>>> If you look through the concrete issues you will find that many of >>>> them are perhaps due to problems elsewhere in the codebase so I guess >>>> the target could be to investigate each issue and then either: >>>> 1. Fix the issue by making changes in concrete and/or small changes >>>> elsewhere. >>>> 2. Ensure that the underlying issue is identified and a label for e.g. >>>> series or whichever part of the codebase is added. >>>> >>>> If you investigate hard enough you will see that there are basic >>>> problems that need changes in the module so actually the best approach >>>> to fixing many of the issues might not be fixing small issues one at a >>>> time. Probably we should fix the definition of Sum so that we don't >>>> have nonsensical results like: >>>> ``` >>>> In [3]: Sum(1, (n, 1, S.Half)).doit() >>>> Out[3]: 1/2 >>>> ``` >>>> Once the definition is clear then at least we know what the right >>>> answer should be for each of the issues. >>>> >>>> Another example of a scope for issues would be piecewise: >>>> >>>> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Afunctions.elementary.piecewise >>>> For piecewise the piecewise function itself is a tighter scope than >>>> the concrete module but the issues all involve other parts of the >>>> codebase. >>>> >>>> There are many different labels that you could focus on. I suggest to >>>> find one where you understand the maths, skim through the issues, and >>>> then try fixing a few. For a GSOC proposal you could read through the >>>> list of issues and write a plan that says what changes could be made >>>> and which issues that would fix. >>>> >>>> On Tue, 4 Feb 2020 at 07:21, Sachin Agarwal < >>>> [email protected]> wrote: >>>> > >>>> > Hello Everyone, >>>> > >>>> > I am Sachin Agarwal, a second year Undergraduate student pursuing >>>> Computer Science Engineering at Indian Institute of Information Technology, >>>> Guwahati. >>>> > >>>> > I regularly contribute to SymPy and have been contributing since >>>> October 2019. I have a profound interest in Mathematics, and am well >>>> familiar with programming languages like C, C++ and Python. >>>> > >>>> > As mentioned by Aaron, we can have a project this summer trying to >>>> fix as many existing issues as possible. I am interested in taking up this >>>> project. >>>> > >>>> > Please reply to this thread if you have any opinions about this >>>> project. >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups "sympy" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to [email protected]. >>>> > To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/sympy/CAM8%3DFcBZ-OWWk4uNspLgOBo%3DVV_p-%3D3QOPXAUKap%3D8czu-6Jig%40mail.gmail.com >>>> . >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "sympy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/sympy/CAHVvXxSE5EmpKEBJBU_EDvWPNQ32-OU9EWP8mzgwqbwpUsj9iA%40mail.gmail.com >>>> . >>>> >>> >>> >>> -- >>> With regards, >>> Gagandeep Singh >>> Github - https://github.com/czgdp1807/ >>> Linkedin - https://www.linkedin.com/in/czgdp1807/ >>> <https://www.linkedin.com/in/gdp1/> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "sympy" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sympy/CAAvS0gWOYzOxnK0rmXqsXePgA3kf7HjTPn_zqbzyMBCwNRM5bQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/sympy/CAAvS0gWOYzOxnK0rmXqsXePgA3kf7HjTPn_zqbzyMBCwNRM5bQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAM8%3DFcCB-BZcdXc%2Buzx5Cqs%3DGRFZAgYMj3gt1DWrU4v9njurAA%40mail.gmail.com >> <https://groups.google.com/d/msgid/sympy/CAM8%3DFcCB-BZcdXc%2Buzx5Cqs%3DGRFZAgYMj3gt1DWrU4v9njurAA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > With regards, > Gagandeep Singh > Github - https://github.com/czgdp1807/ > Linkedin - https://www.linkedin.com/in/czgdp1807/ > <https://www.linkedin.com/in/gdp1/> > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAAvS0gWDdydG4Luh3_RCUZhg%2BxMqBsJxbN1wHjJFL91ytL9HTQ%40mail.gmail.com > <https://groups.google.com/d/msgid/sympy/CAAvS0gWDdydG4Luh3_RCUZhg%2BxMqBsJxbN1wHjJFL91ytL9HTQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAM8%3DFcAaXn8uSfG_JHYTgV6_x%3DvJDKJ_p6dX-CNMPUA984odRw%40mail.gmail.com.
