The last thread about "Posting style" makes me think that effective communication with email is impossible at all in modern world, where time pressure doesn't allow to read responses, not speaking about properly formatting them or following guidelines. The problem with email threads that they can be hijacked, polluted with irrelevant info (context garbage), personal opinions etc. If the aim of the thread is to "sell" some idea, it is almost impossible to track when people change their minds. And the biggest problem is that *email threads are stateless*. Meaning that to get the current state of the problem everybody needs to waste a lot of time to reread the thread and filter it. Sometimes it just takes too much time. So I propose to have a summary for each thread in Etherpad - http://en.wikipedia.org/wiki/Etherpad - that will provide current current summary of email thread, describing original problem, its evolution, arguments and counter-arguments. -- anatoly t.
Created a page for the current thread: http://piratepad.net/python-ideas-an-etherpad-for-every-idea No clone of Etherpad sources. The best way would be to start with Etherpad Lite http://etherpad.org/2012/01/02/a-short-etherpad-lite-talk/ if we are talking about implementation. -- anatoly t. On Tue, Jan 10, 2012 at 8:08 PM, Matt Joiner <anacrolix@gmail.com> wrote:
On Tue, Jan 10, 2012 at 4:31 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
The idea is about collaborative service, not a "community job offer" for single person, responsible to maintain and update summaries for email threads on some wiki page. The architecture should be inspiring for people to provide summaries when they start to find threads confusing, need to organize ideas around the threads or keep the discussion focused.
On 2012-01-11, at 14:55 , anatoly techtonik wrote:
That does not preclude maintaining: 1. Somebody needs to handle the hardware and software stack, check that the load is acceptable, test software updates and deploy them, handle ACLs if any, … 2. Information is not going to self-organize over the whole platform, people will need to keep track of the various documents being created and provide an entry point for the service (linking to various sub-trees) 3. Open-edition systems (wikis, etherpad instances, …) are subject to vandalism, spam and edit wars, there needs to be people and tools able to manage both issues, cleanup the crap in the first two cases and potentially temporarily lock documents in the latter. You're the one who brought it up and suggested it would be a valuable tool, the onus is on you to demonstrate it and it makes sense that you'd be the one maintaining it until then. Hence Antoine's question/suggestion.
Good luck with that.
On Wed, Jan 11, 2012 at 5:02 PM, Masklinn <masklinn@masklinn.net> wrote:
1. Somebody needs to handle the hardware and software stack, check that the
load is acceptable, test software updates and deploy them, handle ACLs if any, …
Does that mean that the idea is good enough to start talking about problems with infrastructure and maintenance? =)
That's right. The idea is to provide an automatic service tied to each email thread, meaning that email threads must be identified first. Then - you're right - there must be a web interface of the entry point that lists threads with pointers to the corresponding Etherpad page. This can further list auxiliary flags, for example if thread was updated after the last change in Etherpad. Etherpad interface then can be tweaked further to implement "approval" system that let's every user place a "tick" next to the reference to a message that the user believes is integrated into summary correctly (or flag messages that are completely missing).
In this case it is possible to limit access to python.org accounts. Is it possible? Is there a central login server for python.org?
I only proposed the idea. If you think this tool won't be valuable then I am open to discuss why. If it is only because I failed to make it a valuable tool then I can make it even more obvious by saying - yes, I will not be able to create a valuable tool out of it alone. -- anatoly t.
Quick Summary: There used to be python-dev summaries. They were great, but too much work.
On Tue, 10 Jan 2012 16:16:09 +0300 anatoly techtonik <techtonik@gmail.com> wrote:
On Tue, Jan 10, 2012 at 4:31 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, Jan 11, 2012 at 11:30 AM, anatoly techtonik <techtonik@gmail.com> wrote:
I only proposed the idea. If you think this tool won't be valuable then I am open to discuss why.
(1) Going to a separate website -- let alone one not at python.org -- is a pain. (2) Creating and maintaining the summaries is a pain. For individual discussions, someone will occasionally post a summary, or even write up a PEP. For the discussions where that doesn't happen, perhaps no one is both sufficiently overwhelmed to need a summary and sufficiently motivated to provide one. Python-ideas was spun off from python-dev. For the python-dev mailing list as a whole, various people have provided biweekly summaries in the past. The summaries were quite helpful. Alas, they were almost never complete, and they all soon slipped into "late" and then got discontinued, because they were too much work to create. Why won't the same thing happen again? Is there something about the Etherpad platform that makes the job much easier? -jJ
E.g. for this discussion: http://openetherpad.org/JlL56IJFYo The farthest this idea can go in my opinion is: 1. Someone makes a bot that auto posts the etherpads to each idea in python-ideas. or 2. Whoever cares enough about an idea will make an etherpad for it if he/she likes to. I don't mind experimenting though. Yuval Greenfield
On Jan 12, 6:00 am, Yuval Greenfield <ubershme...@gmail.com> wrote:
And _both_ options split attention between the list and the etherpad. Which is primary? What happens if someone chooses to participate only on one and not the other? What happens in 6 months when someone else decides that whatever technology du jour they find is cool should be supported as well?
Hello 2012/1/12 alex23 <wuwei23@gmail.com>:
Well, I may be dumb, but ideas seems like non structured draft of PEP. (like IETF RFC drafts), and by looking at PEP 1, I read that it describes a very workflow on how to do things. Maybe python-ideas should only accept ideas in the form a link to a PEP draft and people would have to maintain there draft as long as it is not accepted. http://www.python.org/dev/peps/pep-0001/ So why duplicates already existing procedure and infrastructure ? Maybe amending PEP 1 could be a good way to achieve the aformentioned goal. By not adding a PEP draft that is not accepted in a documentation database, we achieve one of the very first goal of a documentation database which is lowering the Noise Signal Ratio. My .02 cents, -- Julien
On Thu, Jan 12, 2012 at 5:05 AM, julien tayon <julien@tayon.net> wrote:
Seems like you didn't read PEP 1 carefully enough: "Vetting an idea publicly before going as far as writing a PEP is meant to save the potential author time. Many ideas have been brought forward for changing Python that have been rejected for various reasons...." Asking people to write a PEP before discussing ideas would stifle discussion and innovation.
python-ideas is not a documentation database. It's a discussion list. --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
Created a page for the current thread: http://piratepad.net/python-ideas-an-etherpad-for-every-idea No clone of Etherpad sources. The best way would be to start with Etherpad Lite http://etherpad.org/2012/01/02/a-short-etherpad-lite-talk/ if we are talking about implementation. -- anatoly t. On Tue, Jan 10, 2012 at 8:08 PM, Matt Joiner <anacrolix@gmail.com> wrote:
On Tue, Jan 10, 2012 at 4:31 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
The idea is about collaborative service, not a "community job offer" for single person, responsible to maintain and update summaries for email threads on some wiki page. The architecture should be inspiring for people to provide summaries when they start to find threads confusing, need to organize ideas around the threads or keep the discussion focused.
On 2012-01-11, at 14:55 , anatoly techtonik wrote:
That does not preclude maintaining: 1. Somebody needs to handle the hardware and software stack, check that the load is acceptable, test software updates and deploy them, handle ACLs if any, … 2. Information is not going to self-organize over the whole platform, people will need to keep track of the various documents being created and provide an entry point for the service (linking to various sub-trees) 3. Open-edition systems (wikis, etherpad instances, …) are subject to vandalism, spam and edit wars, there needs to be people and tools able to manage both issues, cleanup the crap in the first two cases and potentially temporarily lock documents in the latter. You're the one who brought it up and suggested it would be a valuable tool, the onus is on you to demonstrate it and it makes sense that you'd be the one maintaining it until then. Hence Antoine's question/suggestion.
Good luck with that.
On Wed, Jan 11, 2012 at 5:02 PM, Masklinn <masklinn@masklinn.net> wrote:
1. Somebody needs to handle the hardware and software stack, check that the
load is acceptable, test software updates and deploy them, handle ACLs if any, …
Does that mean that the idea is good enough to start talking about problems with infrastructure and maintenance? =)
That's right. The idea is to provide an automatic service tied to each email thread, meaning that email threads must be identified first. Then - you're right - there must be a web interface of the entry point that lists threads with pointers to the corresponding Etherpad page. This can further list auxiliary flags, for example if thread was updated after the last change in Etherpad. Etherpad interface then can be tweaked further to implement "approval" system that let's every user place a "tick" next to the reference to a message that the user believes is integrated into summary correctly (or flag messages that are completely missing).
In this case it is possible to limit access to python.org accounts. Is it possible? Is there a central login server for python.org?
I only proposed the idea. If you think this tool won't be valuable then I am open to discuss why. If it is only because I failed to make it a valuable tool then I can make it even more obvious by saying - yes, I will not be able to create a valuable tool out of it alone. -- anatoly t.
Quick Summary: There used to be python-dev summaries. They were great, but too much work.
On Tue, 10 Jan 2012 16:16:09 +0300 anatoly techtonik <techtonik@gmail.com> wrote:
On Tue, Jan 10, 2012 at 4:31 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, Jan 11, 2012 at 11:30 AM, anatoly techtonik <techtonik@gmail.com> wrote:
I only proposed the idea. If you think this tool won't be valuable then I am open to discuss why.
(1) Going to a separate website -- let alone one not at python.org -- is a pain. (2) Creating and maintaining the summaries is a pain. For individual discussions, someone will occasionally post a summary, or even write up a PEP. For the discussions where that doesn't happen, perhaps no one is both sufficiently overwhelmed to need a summary and sufficiently motivated to provide one. Python-ideas was spun off from python-dev. For the python-dev mailing list as a whole, various people have provided biweekly summaries in the past. The summaries were quite helpful. Alas, they were almost never complete, and they all soon slipped into "late" and then got discontinued, because they were too much work to create. Why won't the same thing happen again? Is there something about the Etherpad platform that makes the job much easier? -jJ
E.g. for this discussion: http://openetherpad.org/JlL56IJFYo The farthest this idea can go in my opinion is: 1. Someone makes a bot that auto posts the etherpads to each idea in python-ideas. or 2. Whoever cares enough about an idea will make an etherpad for it if he/she likes to. I don't mind experimenting though. Yuval Greenfield
On Jan 12, 6:00 am, Yuval Greenfield <ubershme...@gmail.com> wrote:
And _both_ options split attention between the list and the etherpad. Which is primary? What happens if someone chooses to participate only on one and not the other? What happens in 6 months when someone else decides that whatever technology du jour they find is cool should be supported as well?
Hello 2012/1/12 alex23 <wuwei23@gmail.com>:
Well, I may be dumb, but ideas seems like non structured draft of PEP. (like IETF RFC drafts), and by looking at PEP 1, I read that it describes a very workflow on how to do things. Maybe python-ideas should only accept ideas in the form a link to a PEP draft and people would have to maintain there draft as long as it is not accepted. http://www.python.org/dev/peps/pep-0001/ So why duplicates already existing procedure and infrastructure ? Maybe amending PEP 1 could be a good way to achieve the aformentioned goal. By not adding a PEP draft that is not accepted in a documentation database, we achieve one of the very first goal of a documentation database which is lowering the Noise Signal Ratio. My .02 cents, -- Julien
On Thu, Jan 12, 2012 at 5:05 AM, julien tayon <julien@tayon.net> wrote:
Seems like you didn't read PEP 1 carefully enough: "Vetting an idea publicly before going as far as writing a PEP is meant to save the potential author time. Many ideas have been brought forward for changing Python that have been rejected for various reasons...." Asking people to write a PEP before discussing ideas would stifle discussion and innovation.
python-ideas is not a documentation database. It's a discussion list. --- Bruce Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
participants (9)
-
alex23 -
anatoly techtonik -
Antoine Pitrou -
Bruce Leban -
Jim Jewett -
julien tayon -
Masklinn -
Matt Joiner -
Yuval Greenfield