"Good first issues" on the bug tracker
Hello! Due to the upcoming sprints at PyCon, there will be issues marked in the bug tracker as 'Good first issues'. Please do *not* submit pull requests for these as it is difficult to find suitable issues. Instead of working on these issues, I'd like to propose a much more difficult challenge to current contributors looking for something to work on. Please find issues which can be tackled at the sprint! They are out there, but the trick is finding them. :-) Here's the link to the mentored sprint page to understand the audience: https://us.pycon.org/2019/hatchery/mentoredsprints/ I don't think this needs to be limited to documentation changes, but those are the obvious choice (even the devguide suggests it). The goal is really workflow, meaning the new contributor doesn't necessarily have to solve the problem themselves - if an issue says: x function in y module needs to have z applied, then there's a lot of hurdles there for a newcomer which may not involve solving the problem. If you find anything you think is suitable, please add a comment with 'good first issue' and nosy me or Mariatta on it. If you're unsure, then nosy us anyway. It would be awesome to have too many issues to choose from than not enough. If an issue isn't worked on at the sprint, then it would still be available to new contributors afterwards, so the exercise of flagging the issues wouldn't be wasted effort. Thanks! Cheryl
On 21Feb2019 0557, Cheryl Sabella wrote:
If you find anything you think is suitable, please add a comment with 'good first issue' and nosy me or Mariatta on it. If you're unsure, then nosy us anyway. It would be awesome to have too many issues to choose from than not enough. If an issue isn't worked on at the sprint, then it would still be available to new contributors afterwards, so the exercise of flagging the issues wouldn't be wasted effort.
I agree completely. We normally add the "Easy" or "Easy (C)" keywords to mark these (the latter for issues that involve C code), and these are collected under the "Easy issues" link at the left hand side of the tracker. Any reason to change from this process? Cheers, Steve
I agree completely. We normally add the "Easy" or "Easy (C)" keywords to mark these (the latter for issues that involve C code), and these are collected under the "Easy issues" link at the left hand side of the tracker.
Any reason to change from this process?
Thanks for asking about this. The intent isn't to stop the use of the 'easy' keyword, but to try to reserve some tickets for May. If they are just marked as 'easy', then there could be more of a risk that someone would work on it before the sprints. By assigning them to Mariatta, it will serve the dual purpose of trying to reserve these as well as making them easier to find later on. I think the equivalent would be the ability to add an additional tag to GitHub issues, such as when there's a 'good first date', 'help wanted' and 'sprint' tag on the same ticket. But, I also don't want to complicate the current process, so I apologize if my idea isn't constructive.
I agree completely. We normally add the "Easy" or "Easy (C)" keywords to
mark these (the latter for issues that involve C code), and these are collected under the "Easy issues" link at the left hand side of the tracker.
Any reason to change from this process?
Yeah, I think some kind of separation between the two would be needed in
On Thu, Feb 21, 2019 at 9:59 PM Cheryl Sabella <chekat2@gmail.com> wrote: this case. There are some of us newbies, who frequently click the "Easy" button, so that we find some issue to tackle. Some kind of marking an issue as a "sprint issue" would quickly tell me that the issue is not available to take on. If that's not done, there's the risk that a good number of easy issues would be closed until the sprint.
On 21Feb2019 1258, Cheryl Sabella wrote:
I agree completely. We normally add the "Easy" or "Easy (C)" keywords to mark these (the latter for issues that involve C code), and these are collected under the "Easy issues" link at the left hand side of the tracker.
Any reason to change from this process?
Thanks for asking about this. The intent isn't to stop the use of the 'easy' keyword, but to try to reserve some tickets for May. If they are just marked as 'easy', then there could be more of a risk that someone would work on it before the sprints. By assigning them to Mariatta, it will serve the dual purpose of trying to reserve these as well as making them easier to find later on. I think the equivalent would be the ability to add an additional tag to GitHub issues, such as when there's a 'good first date', 'help wanted' and 'sprint' tag on the same ticket.
But, I also don't want to complicate the current process, so I apologize if my idea isn't constructive.
I'm just trying to keep things easy to search. Keywords are the bpo equivalent of GitHub tags, so if we want a "saved_for_sprint" tag then we should add a new keyword. (In my experience, "sprint" tags on GitHub are normally used on PRs to indicate that they were created at a sprint.) I'm sympathetic to wanting to have tasks for the PyCon sprints, but at the same time it feels exclusionary to "save" them from people who want to volunteer at other times. Having paid to attend PyCon shouldn't be a barrier or a privilege for contributing (though it's certainly a smoother road by having contributors there to assist, which is why other conferences/sprints are keen to have core developers attend as mentors). I'm 100% in favor of discouraging regular contributors from fixing them - we should be *generating* easy issues by describing how to fix it and then walking away. I'm just not entirely comfortable with trying to also hide them from first time contributors. Either way, I'll keep marking issues as Easy when I think they are good first contributions. Cheers, Steve
Cheryl, thanks for starting this thread and for helping to find easy issues to be worked on. I'm sympathetic to wanting to have tasks for the PyCon sprints, but at
the same time it feels exclusionary to "save" them from people who want to volunteer at other times. Having paid to attend PyCon shouldn't be a barrier or a privilege for contributing (though it's certainly a smoother road by having contributors there to assist, which is why other conferences/sprints are keen to have core developers attend as mentors).
I understand your concern, but I hope people understand that the mentored sprint is a little bit different than the regular sprint days. The target audience of the mentored sprint are folks who are underrepresented minorities, in my personal experience, they are less privileged to begin with. We want to be inclusive, and therefore we're encouraging those who are not from underrepresented group to bring along someone else from underrepresented group with them. The mentored sprint is taking place during the main conference days, and looking at the signups, most of the participants have told us they want to sprint for 4 hours on Saturday afternoon. This means they will be missing out on lots of quality talks happening at the same time which they paid for. Our goal is really to make contributing more accessible by paring them up with mentors, but without straightforward issues to be worked on, they can't continue effectively. The issues that's been earmarked for the mentored sprint are so far documentation and typo fixes and not urgent issues. I don't believe that we're "stealing away" opportunity to contribute from those who weren't able to come to PyCon, but I understand that point of view. In any case, I'm appreciative to those who have helped find issues to be worked on the mentored sprint, and I also understand that I can't (and won't) stop other people from working on these issues before the sprint at PyCon. While I'm here, I'd like to invite you all to participate in the mentored sprint if you can. Help spread the word, or sign up to mentor. Any open source project is welcome to sign up! Check the page for more details. https://us.pycon.org/2019/hatchery/mentoredsprints/ I'm a little busy with PyCascades until next Monday, but after that I'll be happy to answer any questions about the mentored sprint. ᐧ
I'm 100% in favor of discouraging regular contributors from fixing them
This would be nice too. Speaking from my experience, it's hard to leave the comfort of what looks to be a quick win (by submitting a PR on an easy issue) and moving on to something where you're more unsure. But...
- we should be *generating* easy issues by describing how to fix it and then walking away.
What a great idea! Maybe that could be written up under the triager section of the devguide as a way to triage. An experienced person can do the legwork, just short of submitting the PR, and then help mentor a newcomer who wants to follow it through. This might be worth a thread on its own.
I'm just not entirely comfortable with trying to also hide them from first time contributors. Either way, I'll keep marking issues as Easy when I think they are good first contributions.
Thanks! :-)
Steve Dower writes:
I'm sympathetic to wanting to have tasks for the PyCon sprints, but at the same time it feels exclusionary to "save" them from people who want to volunteer at other times.
It's already possible to do this sub rosa. Just get a mentor to "claim" the issue, and have a separate page listing them for the mentored sprint attendees. I think it's reasonable for each mentor to claim a couple of issues. Worth a try for a year at multiple sprints, no? If people worry that once it's been done for a year, the mentors will claim it in perpetuity, they can lobby the Council to explicitly sunset the practice, so that the Council would have to act to extend the privilege of reserving issues in this way.
I'm 100% in favor of discouraging regular contributors from fixing them - we should be *generating* easy issues by describing how to fix it and then walking away.
"Generate", of course! But creating a bug report clear enough for another to reproduce and then fix a problem is far more effort than doing it yourself in many, probably most, cases. Some people are already doing this, I'm sure, but to dramatically increase the number of such issues, there would need to be strong incentive for experienced developers to do the extra work.[1] One such incentive might be to require mentors to tag one (or more) easy issue(s) for each one they "claim" for sprints. ("More" would compensate for the possibility that a PR would be generated and applied significantly faster.) The point of Cheryl's proposal is specifically NOT to walk away, but to rather provide in-person mentoring at a sprint. True, this is creating a privileged class from people who can be present at PyCon. We shouldn't award such privileges lightly. But ISTM there are two kinds of mentoring: the first is "patch piloting" the contribution through the contribution process. The second is helping the contributor navigate the existing code and produce new or modified code in good core Python style. It's not clear to me why the first needs to take place at a sprint. The contribution process is entirely formal, and there is no overwhelming need to privilege a subset of potential contributors for "trivial" changes. If this is a reasonable way to look at it, the "reserved for sprint" issues should be difficult enough coding to deserve some mentoring, of a kind that is best done in person. Eg, doc issues (including message and error strings) should be excluded from the reservable class. The mentored sprint new contributors should be encouraged to work on some trivial issues before the sprint. ("Required" doesn't make sense to me, since there are probably a lot who are new to coding entirely.)
I'm just not entirely comfortable with trying to also hide them from first time contributors.
I too feel that discomfort, but there are a number of good reasons to privilege PyCon attendees. The special "mentored sprints" are intentionally diversity-enhancing. If restricted as I suggest, the issues themselves benefit from personal mentoring, and so this will both improve education of new contributors and be an efficient use of mentor time. Finally, these contributors have demonstrated both a financial commitment and a time commitment to Python, an interest in contributing *to Python*, and so are more likely to become consistent contributors than, say, GSoC students who just want to demonstrate that they understand the PR process to qualify for the $5500.[2] Finally, if my analysis above is correct, these issues aren't hidden in any important way. The hidden issues are the ones that get fixed "en passant" as core devs work on something else.
Either way, I'll keep marking issues as Easy when I think they are good first contributions.
Of course! Footnotes: [1] Please tell me I'm wrong about Python! But fixing minor issues "en passant" is my experience in every other project I've contributed to, including as a non-committing "new contributor" in the first few patches. [2] Not saying that GSoC students don't want to contribute *to Python*, just that their financial incentive goes "the wrong way" relative to PyCon attendees.
In the mypy project we've definitely experienced the problem with "beginner" issues that they would be fixed by disinterested folks who just wanted to score some GitHub points, and we stopped doing that. While we've not kept track carefully, my impression is that we've not seen the quantity of contributions go down, and we've seen fewer one-time contributors. There's still the occasional contributor who fixes a doc typo and then is never heard from again, but those are easy to accept (but CPython's PR process is much more heavy-weight than mypy's.) On Thu, Feb 21, 2019 at 10:18 PM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Steve Dower writes:
I'm sympathetic to wanting to have tasks for the PyCon sprints, but at the same time it feels exclusionary to "save" them from people who want to volunteer at other times.
It's already possible to do this sub rosa. Just get a mentor to "claim" the issue, and have a separate page listing them for the mentored sprint attendees. I think it's reasonable for each mentor to claim a couple of issues. Worth a try for a year at multiple sprints, no?
If people worry that once it's been done for a year, the mentors will claim it in perpetuity, they can lobby the Council to explicitly sunset the practice, so that the Council would have to act to extend the privilege of reserving issues in this way.
I'm 100% in favor of discouraging regular contributors from fixing them - we should be *generating* easy issues by describing how to fix it and then walking away.
"Generate", of course! But creating a bug report clear enough for another to reproduce and then fix a problem is far more effort than doing it yourself in many, probably most, cases. Some people are already doing this, I'm sure, but to dramatically increase the number of such issues, there would need to be strong incentive for experienced developers to do the extra work.[1] One such incentive might be to require mentors to tag one (or more) easy issue(s) for each one they "claim" for sprints. ("More" would compensate for the possibility that a PR would be generated and applied significantly faster.)
The point of Cheryl's proposal is specifically NOT to walk away, but to rather provide in-person mentoring at a sprint. True, this is creating a privileged class from people who can be present at PyCon. We shouldn't award such privileges lightly. But ISTM there are two kinds of mentoring: the first is "patch piloting" the contribution through the contribution process. The second is helping the contributor navigate the existing code and produce new or modified code in good core Python style.
It's not clear to me why the first needs to take place at a sprint. The contribution process is entirely formal, and there is no overwhelming need to privilege a subset of potential contributors for "trivial" changes.
If this is a reasonable way to look at it, the "reserved for sprint" issues should be difficult enough coding to deserve some mentoring, of a kind that is best done in person. Eg, doc issues (including message and error strings) should be excluded from the reservable class. The mentored sprint new contributors should be encouraged to work on some trivial issues before the sprint. ("Required" doesn't make sense to me, since there are probably a lot who are new to coding entirely.)
I'm just not entirely comfortable with trying to also hide them from first time contributors.
I too feel that discomfort, but there are a number of good reasons to privilege PyCon attendees. The special "mentored sprints" are intentionally diversity-enhancing. If restricted as I suggest, the issues themselves benefit from personal mentoring, and so this will both improve education of new contributors and be an efficient use of mentor time. Finally, these contributors have demonstrated both a financial commitment and a time commitment to Python, an interest in contributing *to Python*, and so are more likely to become consistent contributors than, say, GSoC students who just want to demonstrate that they understand the PR process to qualify for the $5500.[2]
Finally, if my analysis above is correct, these issues aren't hidden in any important way. The hidden issues are the ones that get fixed "en passant" as core devs work on something else.
Either way, I'll keep marking issues as Easy when I think they are good first contributions.
Of course!
Footnotes: [1] Please tell me I'm wrong about Python! But fixing minor issues "en passant" is my experience in every other project I've contributed to, including as a non-committing "new contributor" in the first few patches.
[2] Not saying that GSoC students don't want to contribute *to Python*, just that their financial incentive goes "the wrong way" relative to PyCon attendees.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Hi, Let me share with you (this mailing list) my experience with mentoring and what we call "easy issue". First of all, almost all "easy issues" are very hard issues: issues open for longer than one year, with many comments, and nobody succeeded to come up with a solution (well, otherwise the issue would be closed, no? ;-)). Does it mean that there is no easy issue? Well, when someone creates a really easy issue, it's usually fixed in less than 2 hours(!): either by a core dev who want to relax their brain, or by a contributor eager to get more commits under their name. It's not uncommon that even if an issue is marked as easy (easy keyword and [EASY] in the title), it's fixed by a core a dev. Or at least by a "regular" contributor who wants to get more commits. For a regular contributor, I see the point of getting more commits: getting more visible. But in my criteria to promote a contributor as a core dev, it's not enough. It's not with easy issue that you learn hard stuff: trade off between backward compatibility and new features which has to break it, write complex test, document properly a change, etc. Does it mean that we don't need easy issue? No. For someone who really starts from the beginning, easy issues are required. You cannot ask a newcomer to immediately write the perfect PR at the first attempt with a long list of strict requirements: complex tests, handle portability issues, etc. You need to build a stair made of *small* steps. What's the solution? I'm not sure. I decided to stop opening public issues for my mentorees and instead give them easy bugs by private email. Why? My main concern is the high pressure on an open issue: the race to be the first to produce a PR. Recently, I opened a public issue anyway but explicitly wrote that it's reserved for my mentoree. Someone ignored the message and wrote a PR... It was a first time contributor and it was really hard to me to reject the PR :-( (My mentoree wrote a better PR with my help, at least a PR closer to what I expected, obviously since I helped.) I prefer to give unlimited time to my mentoree to dig into the code, ask questions, write code step by step. I really hate the time pressure of the race on open easy issues :-( Now the question is: how can *you* find an easy issue? Well. In the past, my real problem was that I didn't let anyone write the code that I would like to write myself. I considered that nobody writes code as well as I do... Sorry :-) It took me time to change my mind. Lao Tsu said that if you give a hungry man a fish, you feed him for a day, but if you teach him how to fish, you feed him for a lifetim To better scale horizontally, I have to teach other people what I do, to be able to distribute the work. I am working hard against myself to stop writing all code myself. Instead, I'm trying to explain carefully what I would like to do, split the work into tasks, and distribute these tasks to my mentorees, one by one. But I don't put my mentorees in a competition, each mentoree has its own project which doesn't conflict with others. Doing that takes me a lot of time: create tasks, follow tasks, review PRs, etc. To be honest, right now, I'm mostly able to follow correctly only one mentoree at the same time. The others are more "on their own" (sorry!). As you may know, finding a task doable by mentorees is hard. I have a lot of ideas, but many ideas will take years to be implemented and are controversial :-) I don't ask you to completely stop writing code. I ask you to not write everything yourself, and sometimes give the simplest issues to contributors who are eager to help you. Victor
I would also suggest cleaning up the existing set of easy issues where the issues was tagged as easy initially followed by discussion about how the though easy has other concerns like backwards compatibility due to which it can't be merged. It's getting hard to get more easy issues and what could seem as an easy fix might later expand into a discussion that the beginner might not have enough context to answer and in that case the easy tag should be removed. It's even harder over realizing when to fix it by myself or tag it as easy for someone to fix it because if it's fixed by a regular contributor then there could be a thought that I myself could have done it since triaging itself is a difficult work. I would also recommend waiting for a core dev or someone to provide some feedback or confirmation on even an easy issue's fix since it's easy to propose a fix to be later rejected due to various reasons resulting in wasted work and disappointment. PS : Using mailing list for the first time apologies if I have done anything wrong. On Fri, Feb 22, 2019, 5:40 PM Victor Stinner <vstinner@redhat.com> wrote:
Hi,
Let me share with you (this mailing list) my experience with mentoring and what we call "easy issue". First of all, almost all "easy issues" are very hard issues: issues open for longer than one year, with many comments, and nobody succeeded to come up with a solution (well, otherwise the issue would be closed, no? ;-)). Does it mean that there is no easy issue? Well, when someone creates a really easy issue, it's usually fixed in less than 2 hours(!): either by a core dev who want to relax their brain, or by a contributor eager to get more commits under their name.
It's not uncommon that even if an issue is marked as easy (easy keyword and [EASY] in the title), it's fixed by a core a dev. Or at least by a "regular" contributor who wants to get more commits. For a regular contributor, I see the point of getting more commits: getting more visible. But in my criteria to promote a contributor as a core dev, it's not enough. It's not with easy issue that you learn hard stuff: trade off between backward compatibility and new features which has to break it, write complex test, document properly a change, etc.
Does it mean that we don't need easy issue? No. For someone who really starts from the beginning, easy issues are required. You cannot ask a newcomer to immediately write the perfect PR at the first attempt with a long list of strict requirements: complex tests, handle portability issues, etc. You need to build a stair made of *small* steps.
What's the solution? I'm not sure. I decided to stop opening public issues for my mentorees and instead give them easy bugs by private email. Why? My main concern is the high pressure on an open issue: the race to be the first to produce a PR. Recently, I opened a public issue anyway but explicitly wrote that it's reserved for my mentoree. Someone ignored the message and wrote a PR... It was a first time contributor and it was really hard to me to reject the PR :-( (My mentoree wrote a better PR with my help, at least a PR closer to what I expected, obviously since I helped.)
I prefer to give unlimited time to my mentoree to dig into the code, ask questions, write code step by step. I really hate the time pressure of the race on open easy issues :-(
Now the question is: how can *you* find an easy issue? Well. In the past, my real problem was that I didn't let anyone write the code that I would like to write myself. I considered that nobody writes code as well as I do... Sorry :-) It took me time to change my mind.
Lao Tsu said that if you give a hungry man a fish, you feed him for a day, but if you teach him how to fish, you feed him for a lifetim
To better scale horizontally, I have to teach other people what I do, to be able to distribute the work.
I am working hard against myself to stop writing all code myself. Instead, I'm trying to explain carefully what I would like to do, split the work into tasks, and distribute these tasks to my mentorees, one by one. But I don't put my mentorees in a competition, each mentoree has its own project which doesn't conflict with others.
Doing that takes me a lot of time: create tasks, follow tasks, review PRs, etc. To be honest, right now, I'm mostly able to follow correctly only one mentoree at the same time. The others are more "on their own" (sorry!). As you may know, finding a task doable by mentorees is hard. I have a lot of ideas, but many ideas will take years to be implemented and are controversial :-)
I don't ask you to completely stop writing code. I ask you to not write everything yourself, and sometimes give the simplest issues to contributors who are eager to help you.
Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tir.karthi%40gmail.com
-- Regards, Karthikeyan S
I would also suggest cleaning up the existing set of easy issues where the issues was tagged as easy initially followed by discussion about how the though easy has other concerns like backwards compatibility due to which it can't be merged. It's getting hard to get more easy issues and what could seem as an easy fix might later expand into a discussion that the beginner might not have enough context to answer and in that case the easy tag should be removed. It's even harder over realizing when to fix it by myself or tag it as easy for someone to fix it because if it's fixed by a regular contributor then there could be a thought that I myself could have done it since triaging itself is a difficult work.
I agree that many issues need to have the 'easy' tag removed. There really isn't a stage on the tracker for 'in discussion' or 'deadlocked'. I
On Fri, Feb 22, 2019 at 11:11 AM Karthikeyan <tir.karthi@gmail.com> wrote: think 'languishing' was the closest status for that. When I've added 'easy' to older issues in the past, I try not to do more than one or two a day. That way, the nosy list doesn't get spammed too much and there aren't too many issues that float to the first page. Maybe something similar for removing the 'easy' tag? Only change a few day, but also leave a comment summarizing the discussion (if it had been long), or just saying "X core dev thinks it should be this way and Y core dev thinks this, so until that is resolved, this is no longer an easy issue." A comment would help because you would have done some research, so that communicates to others what you found out about the ticket. I certainly didn't intend for my first week as a core dev to be about trying to change the workflow, so apologies in advance if anyone thinks this is too drastic.
I would also recommend waiting for a core dev or someone to provide some feedback or confirmation on even an easy issue's fix since it's easy to propose a fix to be later rejected due to various reasons resulting in wasted work and disappointment.
Agreed, but perhaps the most helpful way to do that is to propose the fix in a comment on the bug tracker and then, if a core dev or expert says it's a good idea, then move ahead with it? Although, just recently for IDLE, I made a suggestion on the tracker and then my code wasn't what Terry expected, so sometimes the clearest explanation *is* a code change. But, for any change that someone will spend some time on, then there should probably be consensus first.
PS : Using mailing list for the first time apologies if I have done anything wrong.
You did great! This topic was my first post too, so I know exactly what you mean. :-)
On 2/23/2019 2:50 PM, Cheryl Sabella wrote: AM Karthikeyan <tir.karthi@gmail.com> wrote:
I would also recommend waiting for a core dev or someone to provide some feedback or confirmation on even an easy issue's fix since it's easy to propose a fix to be later rejected due to various reasons resulting in wasted work and disappointment.
Agreed, but perhaps the most helpful way to do that is to propose the fix in a comment on the bug tracker and then, if a core dev or expert says it's a good idea, then move ahead with it?
I agree with both of you as to what contributors, especially new contributors, *should* do. But they sometimes race to 'grab' an issue by (prematurely) submitting a PR, sometimes after ignoring coredev comments and disagreements. I have occasionally said on an issue that a PR was premature. What really annoys me is if I say on an issue "Maybe we should add this sentence: 'jkjsf j fsjk sjkf sjskjfjs sflsj sfjsfjljsgjgeij k fjlfjs.' What do others think?" and within an hour someone who is incapable of writing or even properly reviewing the sentence mechanically copies it into a PR. I see this as intellectual theft and have been tempted to close a couple of PRs as such. -- Terry Jan Reedy
On Sun, Feb 24, 2019 at 1:07 PM Terry Reedy <tjreedy@udel.edu> wrote:
On 2/23/2019 2:50 PM, Cheryl Sabella wrote:
AM Karthikeyan <tir.karthi@gmail.com> wrote:
I would also recommend waiting for a core dev or someone to provide some feedback or confirmation on even an easy issue's fix since it's easy to propose a fix to be later rejected due to various reasons resulting in wasted work and disappointment.
Agreed, but perhaps the most helpful way to do that is to propose the fix in a comment on the bug tracker and then, if a core dev or expert says it's a good idea, then move ahead with it?
I agree with both of you as to what contributors, especially new contributors, *should* do. But they sometimes race to 'grab' an issue by (prematurely) submitting a PR, sometimes after ignoring coredev comments and disagreements. I have occasionally said on an issue that a PR was premature.
I guess it could be due to the initial excitement in contributing to a large project. I must admit I too did some mistakes in my initial set of PRs along similar lines. I guess it's one of the things both someone contributing new and a regular contributor should learn over the course of time that there are cases where the solution might seem important from the perspective of the contributor in getting code merged but provides less value amidst other factors like code maintenance, backwards compatibility, etc. There is also high interest in creating a PR and less on reviewing other PRs (1020 open PRs on GitHub) which could be a separate topic on its own. There could be some action or motivation on making sure there is a balance in the incoming PRs and review bandwidth since there might be a stage where there is a lot of interest or efforts in getting new contributors who create a PR with less bandwidth to review resulting in potentially making them disappointed in having work not reviewed. We should be getting new people on board and it's not that I complaining but this is something that the steering council could discuss upon regarding reviews and there was a recent thread on it [0] [0] https://mail.python.org/pipermail/python-committers/2019-February/006517.htm... -- Regards, Karthikeyan S
Karthikeyan writes:
I would also recommend waiting for a core dev or someone to provide some feedback or confirmation on even an easy issue's fix
FWIW, I don't think waiting on core devs is a very good idea, because we just don't have enough free core dev time, and I don't think we (or any project!) ever will -- if core devs have enough free time to do lots of triage and commenting, they're the kind of developer who also has plenty of own projects on the back burner. OTOH, new developers aren't going to know who the core devs are, and it's probably true that an issue with comments on it is likely to be easier to get your head wrapped around than one without. (I don't know that non-core devs are any more likely to make comments, though.)
since it's easy to propose a fix to be later rejected due to various reasons
This is certainly true, but:
resulting in wasted work
I have to disagree. Learning is hard work, and at least you get to spend that effort on Python doing it the way you think is right. If you got it wrong in the opinion of a committer, you learn something, because they're usually right (for Python), that's how they get to be core developers. The work that I consider wasted is when I tell the boss that the idea sucks and why, they say we're going to do it so STFU and write, and then when they see the product they say "Ohhhhhh."
and disappointment.
Yes. It is disappointing when something you think is useful, even important, gets tabled just before the feature freeze. Especially when it gets postponed because somebody has decided that something unrelated that your code touches that's not broke needs fixing[1] but they haven't decided what that means. My answer to that is to have lots of little projects pending time to work on them, even though I'm not a core developer. FWIW, YMMV as they say. Footnotes: [1] Good luck parsing that, but I'm sure you know the feeling. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
participants (9)
-
Cheryl Sabella -
Guido van Rossum -
Karthikeyan -
Lysandros Nikolaou -
Mariatta -
Stephen J. Turnbull -
Steve Dower -
Terry Reedy -
Victor Stinner