> What’s your opinion—should I try these or focus on other types of issues instead?
My advice is that you shouldn't rely on 'easy to fix' labels. Tagging the issue, often looks laborous and can sometimes be outdated. The other problem is that 'easy' is very subjective and ambiguous qualifier, and the things that look easy for experienced contributors, can often be very unfamiliar and difficult for new contributors. I also didn't made contribution 90% based on that tag, and even my first contribution didn't start with 'easy to fix' issues but identifying some new bugs in SymPy myself. I also think that it is better for your life if you can identify what to contribute yourself, and arrive at your own creative solutions, than expecting others to catch the fish for you. On Sunday, December 15, 2024 at 6:23:23 PM UTC+1 Oscar wrote: > The problem is that the easy to fix issues that are actually easy to > fix typically get fixed quite quickly. So the easy to fix label is a > label that naturally over time accumulates issues that are *not* easy > to fix... > > What makes the issue easy to fix is basically if it is very clear what > the change should be. That might be because: > > - The issue is fixed and all that is needed is to add a test. The > issue already shows the exact code that can go in the test. > - Someone has shown the exact code that can be used and there is no > reason not to use the code as is. > > Many issues are in the first category (already fixed) but are not > listed as easy to fix. This is because it is nonzero work to go > through existing issues and check if they are actually fixed. One > thing that can be done and is very much worthwhile is to go through > existing issues and check if they are fixed. > > In general my advice would be to pick a particular part of the > codebase and read through the issues and pull requests that have the > appropriate label. The full set of open issues is too large and too > broad in terms of topics to be worth anyone going through > individually. Instead though if you are interested in say the ntheory > module then you can look at only issues and pull requests for that by > following the label on github: > > https://github.com/sympy/sympy/labels/ntheory > > Then there are only 50 issues and pull requests to go through. That is > small enough that someone could reasonably go through all of them. > > Also many older pull requests have an interaction that is sort of like: > > - Someone opens a pull request. > - Someone else comments on the pull request asking for changes. > - The changes don't get made and the pull request sits in limbo. > > It is worth looking at both open and closed pull requests to see > examples of this. Often only small changes would be needed to turn the > pull request into something that could be merged and it would be > useful for someone to open a new pull request that is only slightly > different from the previous one. > > One point to be very clear about when basing a new pull request on an > old one is: > > - Be very explicit that the new pull request is based on another one > and show an explicit link to the other one and explain clearly what > the similarities and differences are. > - If the differences are only slight or the new PR just adds > additional changes then it is better to preserve the git commits from > the previous pull request so that the authorship is recognised. > > There have been many examples in the past where someone has not said > that their pull request is based on another one and then been accused > of plagiarism. I think often this is just a misunderstanding but that > is why it is important to be clear if the changes are derived from an > existing PR. > > In general I do think that we should get better at managing easy to > fix issues. Ideally there would be a sort of pool of useful but long > running tasks that new contributors looking for an easy way to make a > useful contribution could do. The problem is they need to be things > that are easy to do, easy to review and not in any way controversial. > In many other Python projects I think adding type annotations comes > into this category but in SymPy it is too controversial and still too > uncertain how they should be used. > > -- > Oscar > > On Sun, 15 Dec 2024 at 13:36, PRAYAG V <v.pray...@gmail.com> wrote: > > > > Since there aren't many 'easy to fix' issues, I’m wondering if you have > any suggestions on whether I should start working on other types of issues. > I’m also regularly checking for new ‘easy to fix’ issues, but haven’t found > anything suitable yet. > > > > Yes, GSoC has always been my dream, and I’m eager to contribute to SymPy > in any way I can. Thanks again for your quick response and helpful guidance! > > > > > > On Sunday, December 15, 2024 at 8:22:18 AM UTC+5:30 Oscar wrote: > >> > >> Often issues are labelled easy to fix but then it turns out that they > >> are not easy to fix but we forget to remove the label. If you see an > >> easy to fix issue that has not been fixed for a long time then comment > >> on the issue to say that it is probably not easy to fix so we can > >> remove the label. > >> > >> On Sat, 14 Dec 2024 at 11:27, PRAYAG V <v.pray...@gmail.com> wrote: > >> > > >> > Hello, I’ve been looking to contribute to SymPy and noticed there are > issues labeled as ‘easy to fix.’ However, many of them have been open for > over two years and don’t seem easy to fix anymore. I’ve been waiting a long > time to find an easy-to-fix issue, but nothing suitable has come up. What’s > your opinion—should I try these or focus on other types of issues instead? > >> > > >> > -- > >> > 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+un...@googlegroups.com. > >> > To view this discussion visit > https://groups.google.com/d/msgid/sympy/64ec097c-1080-40db-8c07-a13d4b752900n%40googlegroups.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+un...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/sympy/4098d752-29f5-4af5-baba-44be527d443fn%40googlegroups.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 visit https://groups.google.com/d/msgid/sympy/f9b5b19a-9e80-4b34-bf5d-4b418b53955bn%40googlegroups.com.
