[Python-ideas] Moving to another forum system where

[Michel Desmoulin]

Le 19/09/2018 à 00:37, James Lu a écrit :
>> Is that really an issue here? I personally haven't seen threads where
>> Brett tried to stop an active discussion, but people ignored him and
>> kept fighting.
> Not personally with Brett, but I have seen multiple people try to stop the “reword or remove beautiful is better than ugly in Zen of Python.” The discussion was going in circles and evolved into attacking each other’s use of logical fallacies. 
> 
> Other than that, my biggest issues with the current mailing system are:
> 
> * There’s no way to keep a updated proposal of your own- if you decide to change your proposal, you have to communicate the change. Then, if you want to find the authoritative current copy, since you might’ve forgotten or you want to join he current discussion, then you have to dig through  the emails and recursively apply the proposed change. It’s just easier if people can have one proposal they can edit themselves.
>   * I’ve seen experienced people get confused about what was the current proposal because they were replying to older emails or they didn’t see the email with the clear examples.
> * The mailing list is frankly obscure. Python community leaders and package maintainers often are not aware or do not participate in Python-ideas. Not many people know how to use or navigate a mailing list.
>   * No one really promotes the mailing list, you have to go out of your way to find where new features are proposed. 
>   * Higher discoverability means more people can participate, providing their own use cases or voting (I mean using like or dislike measures, consensus should still be how things are approved) go out of their way to find so they can propose something. Instead, I envision a forum where people can read and give their 2 cents about what features they might like to see or might not want to see. 
>    * More people means instead of having to make decisions from sometimes subjective personal experience, we can make decisions with confidence in what other Python devs want. 
> 
> Since potential proposers will find it easier to navigate a GUI forum, they can read previous discussions to understand the reasoning, precedent behind rejected and successful features. People proposing things that have already been rejected before can be directed to open a subtopic on the older discussion. 

+1 except for visibility

I have been on this list for years and those issues have been a big
problem ever since.

But I agree with Antoine, quantity is not the problem. Quality is.

However having no way to moderate efficiently means nobody does it,
which means quality goes down. Since you have no way to identify who is
who anyway, you can't know if the person telling you that you are out of
line is an experienced member of the community or a newcomer with a lot
of energy.

Another things is that we keep having the same debates over and over. If
you had the same duplication in code, it would never pass code reviews.
The problem is looking up something, or making a reference to something
is really hard on the list.

A few scenario that seem important to me that are badly handled by this
tool:

- Person A is making a long constructive argument, and person B arrives,
doesn't read anything, and make arguments against things that have been
answered. It should be easy for somebody to link to the answers to this.

- Somebody is making a proposal that has been already discussed and
rejected several times. It should be easy to link to the discussions and
conclusions about this. Even if the goal is to start the debate over
again, at least we start ahead.

- A is telling B this is a bad idea. It should be easy to tell if the
person is experienced or not. You probably don't want to interact the
same way with Victor and Yury, that have done numerous contributions to
the Python core, and me, that is just a regular Python dev and don't
know how the implementation work.

- somebody wants to make a proposal. It should be easy to search if
similar proposals already have been made, and read __ a summary __ of
what happened. The bar to write a PEP is to high to serve that purpose:
most proposal don't ever leave the list.