Python is a volunteer project, if you make a proposal, you are volunteering to make it happen. At a bare minimum we assume you will do research, manage the discussion, respond to and address comments & criticism. Don’t expect others to do tasks you aren’t willing to do. Read more in the Code of Conduct & Setting expectations for open source participation
Read & summarize previous discussion, including of similar proposals. Don’t create a thread if you have nothing to add or to address the reasons they were rejected
Explain why the other ways of achieving the same goals as your idea, i.e its potential alternatives or workarounds, are insufficient
For instance, before asking for something to be included in the standard library, ask yourself why it can’t be shared differently, as a snippet or as a PyPI package
Give clear examples describing how your idea would work
Post followups instead of editing previous posts. Mailing list users only see edits within 10 minutes after posting
There should be no discussion about the contents of your idea before these points have been addressed
Should we add a list of frequently posted suggestions?
I think it’s not very clear what that implies, who it’s meant to, and so on. Maybe after the bullet list “These questions should and are expected to be addressed before anything else when dealing with a new idea.”
Point 6 is not specific to Ideas, so it should probably not be in the bullet list - it can be in the pinned post, but it has nothing to do with “How to create a successful proposal?” proper.
Yes, a list of boomerangs can be included (with links to their respective threads, but at the very end of the post I think.
No, but I think in Ideas there’s a higher chance you want to edit your post to address feedback than in other categories. In Python Help it’s mostly fixing formatting.
I agree with @Gouvernathor - this isn’t something relevant to the ideas category, it’s a general principle of interacting here. (To be perfectly honest, no-one other than you seems to have much trouble with this idea, which is another reason I don’t think it needs to be pointed out explicitly).
While it’s seriously old now (to the point where I’d expect the majority of Python programmers wouldn’t even realise some of the examples were changes that needed to be proposed and accepted at some point in history), my post at Justifying Python language changes | Curious Efficiency is still a decent general summary of characteristics to look for when assessing proposals to change Python-the-language. A modernised iteration on Status quo wins a stalemate | Curious Efficiency would also be worth mentioning.
The Design & History FAQ in the CPython docs is also well worth a visit before proposing changes (and is the preferred venue for recording FAQ answers when needed)
Python is a volunteer project, if you make a proposal, you are volunteering to make it happen. At a bare minimum we assume you will do research, manage the discussion, respond to and address comments & criticism. Don’t expect others to do tasks you aren’t willing to do.
Visit these websites if you haven’t done so already
Read & summarize previous discussion, including of similar proposals. Don’t create a thread if you have nothing to add or to address the reasons they were rejected
Explain why the other ways of achieving the same goals as your idea, i.e its potential alternatives or workarounds, are insufficient
For instance, before asking for something to be included in the standard library, ask yourself why it can’t be shared differently, as a snippet or as a PyPI package
Give clear examples describing how your idea would work
These questions should and are expected to be addressed before anything else when dealing with a new idea.
I believe we should create a new post and unpin the existing one instead of updating it. Otherwise our mailing list users won’t be able to read the updated version. (Also lock it immediately)
Typo (visit), and this should probably be out of the bullet list and after the “These questions should…” part, as we can’t reasonably expect people to read a thesis before posting something. The sentence should not be written in the imperative.
Though that list of things well deserves to be in the post.
Here’s a more prosaic draft inspired by the current pinned thread and @Nineteendo’s drafts.
Please Read Before Posting an Idea
Would you like to change something in Python? This might be the Category for you. Use this Category if you want feedback on an idea that you’d like to see in a future version of Python.
Understand that Python is a volunteer project. Any ideas which are eventually integrated into Python, typically via the procedure outlined in PEP 1, will be developed, implemented and maintained by a limited number of folks volunteering their time to improve Python for the benefit of the community. If you are making a serious proposal you should expect to also volunteer your time to help make it happen. How you help will depend on your skills and experience, but at a minimum you should expect people to assume that you will do your research, manage the discussion, respond to and address comments and criticisms, and not expect others to do tasks you aren’t willing to do.
The following articles give general expectations about how Python is developed and the spirit of the Python community:
Any serious proposal will address the following requirements and questions:
You must research if your idea, or a similar one, has been proposed in the past. If so, then your new proposal must address the reasons why the old proposal did not move forward. Why should the idea move forward now if it didn’t in the past? To find old similar proposals you should, at minimum, check:
Address other ways of achieving the same goals as your ideas. Why are those not sufficient such that you are requesting a change to Python? For example, why can’t a PyPI package suffice to satisfy your idea?
Give clear examples describing how your idea would be used and what problems it would solve.
Answer the questions: Who will develop the source code and documentation for this idea? Who will maintain the source code and documentation for this idea? How burdensome will these jobs be for whatever person (or maybe people) is doing it? How will you personally contribute to the realization of this idea?
Please think about all of these requirements/questions and address them in the topic you create with your new idea. This will save your time, the time of volunteers reading this forum,
Should the pinned post also mention that if an idea is deemed inadequate it will be moved to Python Help? It would explain why you need to look at Python Help for similar proposals in the past, as this can be surprising for those unfamiliar with this forum, and also set expectations for the poster, so that if their post is moved they won’t be suprised.
I’ll edit and fix that typo. Oh I was still drafting that last sentence before I posted, oops. Maybe something like:
Please think about all of these requirements/questions and address them in the topic you create with your new idea. This will save your time and the time of volunteers reading this forum (including core devs who are required to sponsor PEPs) from having to raise and address these topics. Furthermore, addressing all of these ideas up front will make others in this forum more likely to respond and engage with your ideas, increasing the likelihood they may be adopted.
The policy of “moving inadequate ideas to Python Help” has not been finalized as far as I can tell. If that policy is finalized then I guess it should be mentioned in the pinned post. My hope is the post is good enough that we don’t need to move bad ideas. If an idea is inadequate we can leave it in the ideas forum but just respond to the idea pointing them to the pinned post and leave the thread dormant until all the topics in the pinned post are addressed in the idea by the proposer or someone else.
This is IMO a great summary of the previous discussions, and I’d even say a couple of points can be expanded even further. I don’t think conciseness should be a consideration here at all, as discussed the concerns around new ideas are fairly complex and subtle, and it’s better to give them justice and assume that a determined contributer would not be put off by length but actually appreciate the detail.
More concretely, I suggest expanding on the fourth point a bit with the contents of this post to reflect the importance of well-constructed practical examples, and on the third point with this post, especially the part about a recipe in the docs or a utility function.
I don’t know where this should fit (if at all) in the pinned post, but this is a great post about how to manage an idea discussion.
The post addressed specific issues in its thread, but the advices are applicable universally. It’s also cited by a core-dev in a different thread when the discussion went wrong in a similar direction.
The existing drafts we have (by @Nineteendo and @jagerber) mostly focus on how to research for an idea and write a good idea proposal, but are lacking on how to manage the discussion. I think it will be beneficial to add this aspect to the pinned post, using Eric’s post as a starting point.
Should be possible to work that in. I’ll think about it. I also agree that brevity isn’t critical here. Python is a serious language, if people are serious about ideas about it they can take many minutes to read a post teaching them how to make good proposals.
I see. I had gotten the history wrong based on some recent posts. Of course your comment about “digging into how this forum works” is a bit unfair because currently this policy isn’t spelled out anywhere obvious (one of the problems we’re solving now).
In any case, it seems that that policy is under scrutiny right now. I think we’re going to need to pull the rabbit from the hat a little bit and resolve that policy question simultaneously with the wording of this pinned post.
If the policy conclusion is that inadequate ideas will be moved, then yes, the pinned post should clearly spell out that policy. Though I would word it as something like “If your post doesn’t meet the criteria and you don’t show efforts to to bring it up to snuff in a timely manner (what does this mean specifically??? hours? days? weeks?) it will be moved to help”. But my personal hope is that we settle on this not being the policy going forward. Instead we threaten “if you don’t answer these questions there will be little to zero quality interest or activity on your idea”.
yeah, if we’re telling proposers that it’s their responsibility to manage discussions it seems like a good idea to give them advice about how to manage discussions. At least especially how to avoid frustrating pitfalls.