Meta: Lifetime of an idea. 1, 2 & 3

I think Paul is right. That simply makes the description of ideas insufficient:

Would you like to change something in Python? This might be your feedback forum.

Someone looking for a checklist simply won’t find it, and explaining what’s wrong with a proposal is difficult when you can’t link to a detailed summary.

Can we discuss adding a pinned post here?

Actually, I think there’s another problem as well. When we do get something like “I think it would be great if Python allowed type annotations to say which exceptions a function can raise”, far too many existing participants in the group are willing to engage with the idea and repeat all the previous discussions on the topic. This lends credibility to the post, and almost certainly makes it look to the poster as if they had done things correctly. It’s hard to know how to fix this, as it basically means that a lot of the people in this discussion are part of the problem without even being aware of it (myself included, in all likelihood).

Maybe rather than looking to add new categories, or pinned posts, we could do most good simply by not engaging with ill-formed proposals (except for maybe one person explaining to the poster what they should do to get their idea into a state where it will get the right sort of attention).

8 Likes

Can we hold this discussion (and, most importantly, implementation of the post-moving policy) until a pinned post has been added to Ideas ?

2 Likes

By maximizing participation I was talking about participation from people who can help, not participation from people who post ideas. It was a direct response to the problem you pointed out, that many core developers are not participating in idea posts because it’s hard for them to discover well-researched ideas of all ideas.

By lumping less-researched idea posts into the Help category, participation in the Ideas category from the core devs can certainly increase, but those who are interested in all ideas will find it harder to participate in ideas buried in the sea of the regular Help posts, so those Help-bound ideas don’t get the feedbacks they otherwise would had there been a separate, clearly-defined category for them.

We have to recognize that end users of Python can provide perspectives that experienced users who understand the inner workings of Python do not have, and that ideas to improve end user experience may come from, end users.

A good recent example is this idea post of Implicit tuple return type:

Although clearly lacking in details and likely belongs to your “type 1” people, it was still an interesting idea that sparked a good discussion from people who are willing to help, by providing both possible paths forward and arguments against it. It’s what a discussion forum is about after all.

I may not speak for others, but I came to Python Discourse primarily to engage in discussions of ideas, any ideas, to make changes to Python, and much less so to help in help posts because when I feel like helping with help posts I personally find StackOverflow with all the voting/closing/flagging mechanisms helps me find posts that are helpable more easily.

5 Likes

YES! I think this is the path forward.

I think both of these types of posts are acceptable in the ideas category. They are both ideas for how python could be made better.

The problem isn’t people posting these under baked ideas in the ideas category, the problem is that people (feel the need to?) spend precious time responding to these under baked proposals.

As you point out, lots of people will respond even to poorly formed ideas. This may be because they’re new to the discourse, they don’t have history on the previous similar proposals, they just find the conversation interesting, etc.

I think the solution is for the more experience folks to have an easy thing to point to to say “this post doesn’t match these criteria, please satisfy these criteria then the discussion can move on in a meaningful way”. The thing they would get pointed to would include information like “you need a core dev sponsor for your idea to actually get into python. You almost certainly need to meet these criteria for a good proposal before core devs are going to even look at this thread”.

1 Like

I do think that posting them there can waste the time of a lot of people. (Sorry for that, I just wanted to hear the opinion of someone else). Especially since it takes a couple of minutes to realise the proposal is unviable. If there was just a single answer on the question, it might help though.

I think that’s only acceptable to the extent that it’s about the form of the post and not the merits of the idea itself. If someone clearly presents a technically viable, implementable and backwards-compatible proposition to add exceptions to typed signatures, then ghosting them is perhaps one of the meanest and least productive or helpful reaction.

Then we should probably have a stronger thread-closing policy. In cases where the reason leaves no doubt, so where it absolutely is about form - otherwise it just depends on whether the moderator agrees with the proposition or is friend with those who argue against it.

Maybe, but it also serves as a record for why that has been refused before, and save time to (more ?) people in the long run.

1 Like

Good point, and it’s not really what I meant. What I was trying to say is that we as a community need to focus more on mentoring new participants (teaching them what constitutes a good proposal, helping them do the work for themselves, etc) and not doing the work for them (encouraging behaviour that’s ultimately not sustainable, as we’ve seen).

I’m not sure it will work - I’m pretty much burned out trying to encourage people to develop their proposals, and I’ve only held off on muting the Ideas category out of inertia, rather than because I’m getting anything from participation - but IMO it’s the only long-term sustainable approach. As @blhsing said, the alternative is likely to be even more distance between the core dev community and the end users of Python, if the Ideas category turns into an echo chamber with no route for anything to get from there to implementation (because there are no core devs to support or sponsor the good ideas).

3 Likes

I agree with this in theory, but it’s hard to do in practice. If I see an unbaked idea, what am I to do?

  1. Ignore: It wouldn’t be helpful. Someone has to tell the poster what they did wrong and why they’re being ignored.
  2. Reply with “please come back with more research”: It would seem rude, and also unhelpful (e.g. research what?).
  3. Try to guide them what’s wrong with their idea: It would start a conversation and we would be back to where we are now.

I don’t think it’s impossible. With finesse, you can do #2 without coming off as rude and also give some form of guidance without slipping to #3. But it’s not practical to rely on human communication getting it right every time. So why not automating it? A pinned post and/or an idea template is a reliable way to communicate this.

1 Like

Yes, I wonder if Discourse can be configured like GitHub issues or pull requests where when you submit one the text area is pre-filled with a template with clear sections and instructions.

While I’m deeply empathetic to the challenges of new users, I also think it’s incredibly important to protect the mental health of our core devs who actually make the language work. And as you mention, if core dev engagement continues to decline because of the challenges of the category, then that’s a loss for everyone.

There’s been a lot of discussion in this thread on the potential solutions, but after reading through 109 (now 110) posts in this thread, I’m not sure everyone has even agreed on what the basic problem we’re trying to solve is.

So - my question to you, if you’re willing to put some clock cycles towards it - As a Core Dev, what are the problems with the Ideas category as-is that are making you not want to participate in it?

It can, and this is one thing under discussion in this other thread

1 Like

If no-one else has responded, explain to them what they are getting wrong and help them to fix it (your option 3). If someone else is already doing that, there’s nothing for you to do.

If your help turns into a longer discussion, take it to direct messages, so that you don’t have a mentoring session going on in the public forum. Conversely, if you’re not willing to mentor the poster, just say nothing and let someone else do so. Or if you prefer, say something along the lines of “Sorry, your idea needs more development to be useful here - I’m not able to offer you any advice, but hopefully someone else will (or you may be able to get a better sense of what’s needed by reviewing other posts in this category to see what a successful idea should look like)”.

Posters are looking for human interaction. We may not always get everything right, but if we’re not here to interact with other people, what’s the point? Nobody’s expecting perfection, just a willingness to help. (Mentoring is hard and it’s a lot of effort. But we either want people to get involved, or we don’t. In some ways it’s as simple as that).

Because no-one likes getting an automated response.

Thank you for that comment. It’s genuinely appreciated.

Basically, my problem with it is that it’s becoming a forum for people who want things from Python, as opposed to people who want to contribute to Python. While I appreciate that not everyone has the expertise to contribute (for example) C code to implement a highly optimised data structure into Python’s stdlib, I do expect people to participate with an attitude of “if I’m not willing to do the work myself, what right to I have to expect anyone else to do it for me?” And it’s not necessarily anything specific that I want them to do. It’s just an approach - if someone says “this has come up before” then go and look rather than saying “can you give me a link?” (if they could do so without effort, they would have!)

Often people post to the ideas category without even properly understanding how Python works. Ideas along the lines of “all iterators should have a map method” show that the poster doesn’t know that iterator is a protocol rather than a base class - and quite possibly doesn’t even understand what a protocol, of duck typing, is. Many ideas that are of the form “language X does this, why can’t Python?” (whether that’s explicit or implied) demonstrate this lack of willingness to even learn how Python works.

For me, it’s important to remember that the ideas category is for doing language design. If you don’t know anything about language design, and about how Python in particular works “under the hood” (in the broadest sense, at least) then maybe go away and find out before joining in? Or maybe stay, but read the ongoing discussions before starting to post yourself. Too few people bother to lurk and get a sense of the community before barging it. Hence low-quality “drive by” proposals :slightly_frowning_face:

To give a somewhat silly example, I’d be quite happy to sit in the pub with some friends and discuss “wouldn’t it be nice if my car could go on water like a hovercraft?” But I’d never even think of going into my local garage and suggesting to the mechanics there that my car should go on water like a hovercraft. IMO, the ideas category is the garage, and the help category is more like the pub.

The last thing I want is to try to claim any sort of authority simply by virtue of being a core dev, or having been around a long time, but at the same time, I get very frustrated when people come into the ideas category and make proposals or claims without taking any account of the history, or showing any signs that they are willing to listen to people who clearly have more experience than they do (the mere fact of saying “this has come up before” is evidence that “I’ve been around long enough to have seen previous versions of this proposal”).

I hope that’s of some use. It was a bit of a brain dump, as I don’t have much spare time this evening.

16 Likes

As another core dev, I want to highlight this as Paul putting into words a feeling I couldn’t name. The rest of his post from here rings true for me as well.

11 Likes

Those responses make a lot of sense. One thing that stands out is that there’s a tension between a) the desire to have a forum of contributors and b) the need for broad feedback about the decisions the contributors are making.

I first got involved in this forum to provide some feedback on a feature that I very much wanted to see adopted–and it seemed like broad feedback[1] was important in that conversation.

Since then I’ve seen many threads that contain something like “we should find out what the folks working on foo think about this idea”. The foo folks are not able to contribute to python directly–they’re too busy with foo–but their input is valuable as a group of users, so they participate. Iterate on that process a bit and you end up with a lot of forum members who love to talk about Python but can’t volunteer their time to work on developing it.

Sadly I think moving to Discourse, by making these discussion far more open and accessible, has exacerbated the effect that can be frustrating for core devs.


  1. from many other people, not just me ↩︎

1 Like

As another core dev, I want to highlight this as Paul putting into
words a feeling I couldn’t name. The rest of his post from here
rings true for me as well.

I think this may also signal a shift in the composition of the
Python community. Viewed through the lens of an open source
developer, the category description (“Do you want to change
something…?”) makes sense, and is asking whether you’re ready to
roll up your sleeves and make it happen. From the perspective of a
user of mostly proprietary software, the way you “change something”
is to beg/pester the people who maintain the software until they
agree to do it.

3 Likes

Absolutely. I’ve made a similar point before. But while new posters shouldn’t be blamed for their background, they should still make more of an effort to understand the dynamics of the group they want to interact with before starting to speak. Just like you would in a face to face group…

Not really. The way you should do it is by submitting a feature request to someone you pay to do the work. Specifically, there’s always someone paid to do work for you involved. The culture of using free stuff while still acting as if you’re entitled to support contracts and features on demand, is unfortunate and damaging to the industry as a whole, and it’s not something we should tolerate. The individuals posting here can claim some mitigation on the basis that they don’t know any better, but they should find out - it’s basic manners after all.

2 Likes

Can I ask kindly to participate in the discussion about the contents of the pinned message?
The opinion of 1 core developper is not enough and I can’t do this on my own.

1 Like

Really? I thought that was the way you change nothing. That’s how it is with most poprietary software. Unless you have a SLA, you can’t even complain that it isn’t working properly. Most companies seem to be of the opinion that, even after you pay them a whack-ton of money on a regular basis, you still have no rights to the software, and if their servers happen to be down today, you’re out of luck.

Of course, they have a feedback page. If you’re lucky, they will even let you upvote other people’s suggestions, to give you the warm fuzzy feeling that your voice is being added to a growing group.

On a less cynical note, though: It doesn’t matter HOW upvoted a feature request is, it’s still the author’s choice what they write. And you can get tens of thousands of signatures on a petition to get the US Government to build a Death Star but I’m sure you’ll agree that that’s not going to happen.

But, ultimately, you won’t achieve ANYTHING without putting together a workable proposal - and that takes a lot of effort. Doesn’t make any difference whether the project is proprietary or open source, a massive corporation or a single person, hugely popular or niche - this is going to be true of pretty much all of them.

1 Like

*dies, good read


New draft: