Seeking Guidance on Contributing: No Progress with 'Easy to Fix' Issues
152 views
Skip to first unread message
PRAYAG V
Dec 14, 2024, 6:27:29 AM12/14/24
to sympy
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?
Tilo RC
Dec 14, 2024, 7:57:29 PM12/14/24
to sympy
I presume you might be trying to do a bug fix for the GSOC requirement? I did GSoC two years ago, and finding a bug I could fix wasn't easy. What worked for me is that I would frequently check for new issues and think about whether I had any idea how to fix them. Not all issues that are easy to fix are labeled as such. Eventually I found something from the geometry module that I was able to understand.
The first step to fixing any issue is to reproduce the bug yourself so I would start with that. You should also try to reproduce the bug with the development version of SymPy as its possible the bug got fixed by some other changes.
Hope my advice helps!
Hope my advice helps!
Oscar Benjamin
Dec 14, 2024, 9:52:18 PM12/14/24
to sy...@googlegroups.com
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.
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.
PRAYAG V
Dec 15, 2024, 8:36:30 AM12/15/24
to sympy
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!
Oscar Benjamin
Dec 15, 2024, 12:23:23 PM12/15/24
to sy...@googlegroups.com
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
> To view this discussion visit https://groups.google.com/d/msgid/sympy/4098d752-29f5-4af5-baba-44be527d443fn%40googlegroups.com.
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
Sangyub Lee
Dec 15, 2024, 9:02:53 PM12/15/24
to sympy
>
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.
Reply all
Reply to author
Forward
0 new messages