I am new to the Python development process and I need an advice how I can realistically move the Pull Request forward.
I have created a pull request 22431 for the 9 years old issue14243. As there was no clear decision in the bug discussion which way to go, I have chosen the solution from the discussion, which I though was the most appropriate.
Now, 7 months later, I still didn’t get any formal feedback on my PR, and on the bug discussion there is still no definitive way forward agreed as everybody has a slightly different idea.
So, my question is: what is the way to move this all forward?
Who is the one, who can take decision which way to go in case there are different opinions? What is the decision taking mechanism in the Python community?
I agree that there’s a workflow issue here. The problem is that pretty much everyone agrees that the current behaviour is suboptimal, but there’s no consensus on the best fix.
One reason this particular case is hard to judge is that there’s a backward compatibility question. Is it better to fix a problem by introducing backward incompatible behaviour, or to fix it by adding a new feature that in essence allows the user to select the non-problematic behaviour, while leaving the existing backward compatible behaviour as the default?
(I’m deliberately not stating my preferences here, as I want to keep the focus on the procedural issue. I hope my description was reasonably unbiased.)
Decision by consensus is not working here, but there’s no “expert” listed for the tempfile module, to make a unilateral decision. And yet this is too trivial to need the SC to be involved.
One possible way forward is for some core dev to just make the decision, on the understanding that it’s an essentially arbitrary choice at this stage and we’re no longer looking for everyone to agree, just for someone to take action. I’m willing to do that, if we can’t find a better solution.
PS @Ev2geny one thing you will need to do is to update the docs (
Doc\library\tempfile.rst) as part of your PR. But it’s fine to wait on that until we know the way to proceed.
after reviews and updates the pull request has now been marked as awaiting merge.
Question: are there any actions expected from me? Is there a need for me to do anything to make sure it is merged? or will it just happen automatically?
E.g. I see, that there is a conflict with
Lib/tempfile.py now (wasn’t there before). Who is supposed to fix this?
You are the best person to merge the conflict. After that one of the core devs who reviewed it should merge it (I think it’s @steve.dower only on this PR).
Guido, thank you!
I will merge the conflict.
Just out of curiosity, why for this particular PR this is only @steve.dower who can merge it?
How is decided in generally who of the core developers merge the PR?
Also, is there anyone overlooking all PRs and reminding the core developers on outstanding PRs?
There’s nothing formal, but typically the core dev who was most active (or most recent) in the review handles this. IIRC Steve (as
@zooba) reviewed your PR. (There were a few other reviewers but they aren’t core devs.)
Nope, it’s up to each developer to decide on the best workflow for them personally. Remember that we’re doing this as volunteers. If as a contributor you feel your PR isn’t getting the attention it deserves, within the context of the other PRs and issues on the project, you are welcome to ping the core dev reviewer, just don’t be a pest and give them some time. There isn’t any particular hurry for most PRs.
Looks like new changes have been requested (the risk of drawing attention to your PR ), so I’ll re-review once those have been made.
I’ve managed to get better at watching GitHub notifications these days, so will likely notice when it’s updated. Since no other core devs seem to be taking an interest, I’ll merge it this time - normally if I approve and don’t merge it’s because I want to give other core devs a chance to look at it.
thanks for explanation!
P.S. IMHO one of the reasons Python has become so popular is because you managed to create a spirit and a mechanism of community development, thus unleashing the intellectual crowd funding, whilst still having the control and release management.
This is one of the reasons I created this PR, just want to see how it all works from inside.
Dear all, the PR has now been merged (thank you everybody for help).
Last question: I see, that the github issue 58451 only mentions in the header the original (abandoned) PR 22431 and not the final merged PR 97015.
Who can I ask to fix this?
I’ve edited the initial post on the issue.