On 07/10/2014, at 7:15 AM, PJ Eby <p...@telecommunity.com> wrote:
> As before, you can find a "living" HTML version of the draft in progress at:
>
> https://gist.github.com/pjeby/62e3892cd75257518eb0
>
> (In addition to nice formatting, it also has a clickable table of contents.)
>
> After the next round of feedback, I plan to convert this to reST and
> get a PEP number assigned -- assuming nobody comes up with a killer
> problem that sends me back to the drawing board, of course. ;-)
For those who were not aware, I personally haven't commented as yet on this
discussion because I have been on a holiday for the last few weeks and I wasn't
going to allow a discussion about this to ruin my holiday.
I haven't caught up yet on all the discussion, but it is sad to say that it has
headed down a direction exactly as a I warned Robert Collins in private
discussions would likely happen, with certain people trying to rush things to
push their own specific idea for how things should be done, with the risk that
that will dominate the agenda and so push Robert out of the way as far as
trying to coordinate this as a community effort where anyone could feel
confident about providing input with the result then also being a community
effort.
So PJE, please step back and do not go rushing out to create a PEP. That is the
worst thing you could do at this point and will only serve to deter people from
the community contributing and so stifle proper discussion about this whole
topic. You have no more experience or mandate to be specifying a standard for
this than anyone else. By creating a PEP though that gets perceived by many as
meaning the discussion is over. This is exactly what you did for PEP 3333 and
which caused previous discussion about improving WSGI to get shutdown. The
result was that the only thing that really got addressed in PEP 3333 was Python
3 compatibility and a lot of the other bits of the WSGI specification which are
poorly defined, contradictory or restrictive and which cause WSGI server and
application developers pain never got addressed. If that prior discussion
hadn't been shutdown in that way, we could have been using a better defined and
improved WSGI years ago already.
Robert has stuck his neck out to try and bring various parties together to work
on this where anyone who has an opinion or idea can raise them so we as a
community can all together come up with something which is workable for both
server implementers and web application developers.
Robert even setup a github repo specifically as a place to bring together all
those ideas and described how people can add stuff there. For whatever personal
reason you have decided to ignore that repo Robert set up and decided to go
alone. If you have an issue with the way the repo was structured which didn't
make it easy for you to contribute your work into it, then work with Robert to
address that. Right now, that you have created your own separate space for
writing up a specification which you are now trying to rush into a PEP comes
across as you not really wanting to co-ordinate with Robert on this as a
community effort with it instead appearing that you think you know better than
anyone else and nothing anyone else says will be of value. In the face of that,
it is hardly surprising that no one has really responded to what you have
proposed.
So slow down. This is not a race to see who can be the first to come out with a
PEP and so dominate the discussion, it is meant to be a community effort.
Robert. What I would suggest you do is reboot this whole effort.
Go back and perhaps look at how the github repo you setup is structured and
make it more obvious how anyone can add their work into it in separate areas of
it as need be and not just as issues, if that isn't already clear enough.
Document exactly what you want people to do as far as adding anything there.
Find people who will work with you on making all this clearer and defining any
process.
The next step is to make a more definite statement about the timeline for this
whole discussion.
Specifically, give notice of a formal request for comment period and publicise
it through any Python blogs of the PSF that might be able to be used, as well
as through the different Python web communities. Also get prominent individuals
in the Python WSGI and web community to also publicise the comment period.
Set a specific date for the end of that comment period. There should be no rush
on this and people should be given adequate time to respond. Most interested
parties would only do this in their spare time and employers aren't going to
allow them to waste their work time on it. So make the comment period something
like 2 months from the date of announcing it.
What can people comment on?
They may want to comment on the process itself of how we get to the various
specifications that may come out of this.
They may want to comment on what should even be addressed in any revisions or
extensions to the WSGI specification. In other words, don't limit this to just
HTTP/2 and web sockets support. Allow people to raise their pet peeves about
the existing WSGI specification so we can perhaps properly address them this
time. The whole ASYNC issue with existing WSGI applications also should not be
ruled out of scope as far as the comment period.
Finally and hopefully, rather than people just complaining about things or
giving wish lists, they will present properly fleshed out ideas for how to
concretely solve ideas around ASYNC, HTTP/2 and web sockets.
The point is that this should purely be a period for collecting information as
was I believe your original intent. Make it easy for people to contribute, but
defuse the idea that it is a competition or race played out on the WEB-SIG
mailing list, to see who is better, and so take the heat out of the discussion
by simply having people put their ideas in the github repo for later review in
a followup step.
Make it absolutely clear that the intent is not for people to start pushing out
PEPs as competing proposals. Such a path is only going to be detrimental to the
long term success of all this and make people in the community feel that they
are unable to participate because of the higher expectations of what has to go
into a PEP.
At the end of the comment period would then come a period of review of what is
submitted to better define the scope of what seems sensible as far as what can
be tackled. Not every idea has to be addressed. Set a time line you would
expect for that review to take place, but specifically say that how long it
will take is going to be fuzzy as how that review is even to be run would have
to be worked out first.
Then from that review, a scope of work can be specified and broken out into
different working groups using any proposals by people submitted during the
comment period as a basis.
Yes Robert, I understand that this is how you want things to work, but the
structure and timeline has to be better specified as an overall process.
If you don't then you will keep getting people who think that they can ignore
the process you want followed and set their own agenda.
Once the process is better defined, then we as a community can say, work within
it, or go away.
Graham
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
