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 <oscar.j.benja...@gmail.com> 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 <sachinagarwal0...@gmail.com> > 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 sympy+unsubscr...@googlegroups.com. > > 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 sympy+unsubscr...@googlegroups.com. > 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAAvS0gWOYzOxnK0rmXqsXePgA3kf7HjTPn_zqbzyMBCwNRM5bQ%40mail.gmail.com.
