Pinning a post with the expectations could help with preventing half-baked ideas. e.g.
Current draft: GitHub - nineteendo/welcome-to-python-ideas
Pinning a post with the expectations could help with preventing half-baked ideas. e.g.
Current draft: GitHub - nineteendo/welcome-to-python-ideas
When we have come to a conclusion, we can ping the moderators to add the post.
If you would prefer a GitHub repository or something else to work on the draft, let me know.
Maybe wait for the other thread to come to a conclusion first? We haven’t agreed on the general way moving forward yet, it’s too early to talk about specific wording of the pinned post.
(I myself agree with this solution, but that’s not the point.)
-1. People don’t read pinned posts; it won’t achieve much, and particularly with the wording you’ve suggested, it makes the Discourse look extremely hostile.
We are not Stack Overflow and we should not give the impression that we are.
I would read it before posting a new idea in 2025. And even if people don’t read it, it makes it much easier to explain what’s wrong with their post (see 4. in the pinned post) without needing to write a page of text every time.
I’ve simply linked the only wording that has been proposed so far, and it definitely needs to be improved, but not by me. I’m the last person to explain what a good idea looks like as I don’t even know myself.
I’ve simply linked the only wording that has been proposed so far,
and it definitely needs to be improved, but not by me. I’m the
last person to explain what a good idea looks like as I don’t even
know myself.
Yes, I posted that as a straw man because I don’t like to make a
suggestion without at least including an attempt at satisfying it,
so discussion can keep moving toward an actual resolution. It’s
often easier to reason about what’s wrong with a statement and make
revisions than it is to get started.
I agree that the proposed wording is no good. And Chris is right, no-one will read the pinned post before posting. But a “FAQ” style of pinned post, maybe entitiled “How to create a successful proposal” might still be good as a reference to point people at.
Another option, in combination with a pinned post, is to create a template for new posts in Ideas. I wouldn’t want such a thing for most categories, but if the plan for Ideas is that new threads should be somewhat “meaty” in terms of the proposal, it might be helpful to provide people with an outline.
The template could take the rough shape of a PEP, but of course it doesn’t need to be as complete. Here I’ve just copied sections from PEP 1 and removed some that I think are less critical for an initial proposal[1]:
- Abstract – a short (~200 word) description of the technical issue being addressed.
- Motivation – The motivation is critical for PEPs that want to change the Python language, library, or ecosystem. It should clearly explain why the existing language specification is inadequate to address the problem that the PEP solves. This can include collecting documented support for the PEP from important projects in the Python ecosystem. PEP submissions without sufficient motivation may be rejected.
- Rationale – The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
- Specification – The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for at least the current major Python platforms (CPython, Jython, IronPython, PyPy).
- Backwards Compatibility – All PEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The PEP must explain how the author proposes to deal with these incompatibilities. PEP submissions without a sufficient backwards compatibility treatise may be rejected outright.
I don’t know 5. Specification
is always necessary for an initial Idea post, but for some ideas it would be (e.g. a syntax change needs to be pretty specific to be usefully discussed). In most cases there has to be some initial specification and rationale.
A pinned post could go into more detail on how to fill this stuff out, perhaps including common pitfalls and things to think about[2]. It’d be particularly useful is some guidance on where to look for previous ideas and discussions (the PEP page, the mailing lists, and searching this forum, including the Help category)
How about 1 sentence? 200 words is a lot. e.g.
This idea allows to create frozenset literals, which is currently not possible.
I agree it’s a lot–I was just copying the descriptions from PEP 1 as a starting place.
I don’t think the template should actually refer to PEPs–people sometimes don’t realize that a PEP requires a core dev sponsor. It might be confusing to suggest that they are about to write a PEP when they haven’t received any feedback yet. But I think those sections are a good outline of what an initial proposal might look like.
There isn’t really a “previous discussions” section there, but that would be good to list as well. And I think the specification section is tricky because it can be fairly fluid (“include X in the stdlib” doesn’t need an initial spec, but new syntax does).
Strongly agree with this style of helpful reference over law-to-be-followed.
Pinned posts are valuable for the people who pin them (and other frequent posters of the forums), making it easy to just link to something and go “Hey, check this out, maybe it’ll help you.”
And one sentence is not enough. In this case, the motivation should include why you would want to create a frozenset literal. Just something not existing right now is not enough of a motivation to add it. In fact, 200 words might be a good guideline still, especially because providing a good motivation is one of the primary things an initial idea will need to succed (the details can all be hashed out later. A constantly changing motivation is just going to lead to unfocused discussions)
Just a list of things that IMO should be included as places to check:
This is the current pinned post, for your reference in case it is unpinned:
This is NOT the motivation, this is just a short description. It NEEDS to be followed by a motivation.
Why can you unpin posts? I didn’t realise I did that:
That defeats the purpose of entire purpose of having it pinned…
As I pointed out before, this threat is not necessary before voluntary compliance is tested first.
The wording needs to be improved (since fungi agrees), but implementing the policy of moving ideas out of Ideas without explaining that policy in a pinned post is absolute nonsense. I think we would benefit from a pinned post in any case, though.
In particular, don’t propose ideas that have already been the subject of rejected PEPs unless you fully understand why they were rejected previously and can address all of the rejection reasons and offer a new justification that warrants recosnidering the proposal.
And don’t ever propose including a third party library unless you are the author of it (or just maybe, if you have the author’s active support for the proposal - and even then, the author should be willing to get involved in the discussion, so why can’t they just make the proposal themselves as well?)
I’m a pretty strong -1 on a template, especially one as prescriptive as the one you suggest. This is still the Ideas forum, after all. But conversely, I think people should be reminded (in a pinned post) to consider the following:
Ok, but that recommendation doesn’t apply to reimplementing the purpose of a 3rd party lib inside the stdlib. (Of course, in that case, other questions arise.) The distinction should be clear.
And should we forbid that if the 3rd-party lib has a permissive license ? Extreme case, public domain or CC0.
+1 on the rest
Perhaps not a prescriptive template, but I think some sort of guide that is front-and-center when starting a thread would be useful.
Maybe the content I outlined above could go in the pinned post but the template tool can be used to remind people about that post, before they post.
Perhaps not a prescriptive template, but I think some sort of guide that is front-and-center when starting a thread would be useful.
Some kind of gentle guide of things to include, how to format your post, questions you should consider answering would be helpful.
But I’m not so sure about including it front and center when someone wants to post.
It’s a tradeoff between a slight inconvenience for frequent posters (but how often are you starting a new thread in Ideas ?) and hopefully nudging new posters into putting more thought into their proposals.
I can understand that it might feel distasteful but then what are we talking about here?