Am 23.09.2010 07:32, schrieb Jack Diederich:
On Wed, Sep 22, 2010 at 11:46 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Sep 22, 2010, at 6:24 PM, R. David Murray wrote:
On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy tjre...@udel.edu wrote:
deputed tracker authority/ies. Not
That's right. It is true that it isn't branch-specific information,
and that does cause a little bit of irritation for me too, but neither
is Misc/developers.txt or Misc/maintainers.rst.
Of course, we might consider a separate HG repository (I'm all in favor
of many small repos, instead of a
Am 23.09.2010 04:35, schrieb Steven D'Aprano:
On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote:
Yikes - Mark has done terrific work in some very demanding areas,
I'd hate to see him feel unwelcome. So that's my advice: find a
way to smooth this over. You're welcome ;-)
I'd like to
In article
aanlkti=blcbdze7or7ynpnqcbmlxaeidhejerkxso...@mail.gmail.com,
Jack Diederich jackd...@gmail.com wrote:
Likewise for mailing list subscriptions. Personally I've gone back
and forth between subscribing to everything (-list -dev -commits -bugs
-ideas, et al) and subscribing to almost
On Thu, Sep 23, 2010 at 08:40, Georg Brandl g.bra...@gmx.net wrote:
Of course, we might consider a separate HG repository (I'm all in favor
of many small repos, instead of a gigantic sandbox one).
+1.
Cheers,
Dirkjan
___
Python-Dev mailing list
deputed tracker authority/ies. Not everyone has the same idea about how
to handle the various fields and processes. Who decides in cases of
disagreement?
We discussed this a while back and I don't think we really have a tracker
BD. Brett and Martin come closest, but mostly we just sort
Am 23.09.2010 09:18, schrieb Martin v. Löwis:
deputed tracker authority/ies. Not everyone has the same idea about how
to handle the various fields and processes. Who decides in cases of
disagreement?
We discussed this a while back and I don't think we really have a tracker
BD. Brett and
Stephen J. Turnbull a écrit :
What really saves the day here is not that common encodings just
don't do that. It's that even in the case where only syntactically
significant bytes in the representation are URL-encoded, they *are*
URL-encoded. As long as the parsing library restricts itself to
On 23/09/2010 09:46, Georg Brandl wrote:
Am 23.09.2010 09:18, schrieb Martin v. Löwis:
I personally think that the tracker fields and how they should be set is
of minor importance. If there is a bug in Python, the most useful
contribution is to submit a fix (or provide a rationale why this is
Sorry for the late reply. I would really like to see this fixed.
Or we [...] deprecate binascii.(un)hexlify().
...
binascii is the legacy approach here, so if anything was to go, those
functions would be it
...
I'm not entirely convinced binascii is the legacy approach. What makes this
module
Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to pen a dos-and-donts (which I might do anyway, simply
as a blog entry...)
Can you
On 23/09/2010 10:38, Martin v. Löwis wrote:
Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to pen a dos-and-donts (which I might do
On Thu, 23 Sep 2010 13:32:07 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Triaging and closing bug reports are
not the only functions of the tracker, and in fact they are subsidiary
to actual bug-fixing work.
+1. What we really need is people analyzing issues, posting patches or
On Wed, 22 Sep 2010 21:24:49 -0400
R. David Murray rdmur...@bitdance.com wrote:
deputed tracker authority/ies. Not everyone has the same idea about how
to handle the various fields and processes. Who decides in cases of
disagreement?
We discussed this a while back and I don't think we
On Thu, Sep 23, 2010 at 2:40 AM, Georg Brandl g.bra...@gmx.net wrote:
That's right. It is true that it isn't branch-specific information,
and that does cause a little bit of irritation for me too, but neither
is Misc/developers.txt or Misc/maintainers.rst.
Agreed. I'd rather those were
On Thu, 23 Sep 2010 00:29:51 -0400
Fred Drake fdr...@acm.org wrote:
On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannon br...@python.org wrote:
the first thing on the agenda is a complete rewrite of the developer
docs and moving them into the Doc/ directory
I'd like to know why you think
Am 23.09.2010 11:43, schrieb Tim Golden:
On 23/09/2010 10:38, Martin v. Löwis wrote:
Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to
On 23/09/2010 10:59, Antoine Pitrou wrote:
On Thu, 23 Sep 2010 13:32:07 +0900
Stephen J. Turnbullstep...@xemacs.org wrote:
Triaging and closing bug reports are
not the only functions of the tracker, and in fact they are subsidiary
to actual bug-fixing work.
+1. What we really need is people
On 23/09/2010 11:11, Antoine Pitrou wrote:
On Thu, 23 Sep 2010 00:29:51 -0400
Fred Drakefdr...@acm.org wrote:
On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannonbr...@python.org wrote:
the first thing on the agenda is a complete rewrite of the developer
docs and moving them into the Doc/
Hi.
I have an issue which has been annoying me from quite sometime and any help
would be greatly appreciated:
I just installed Python 2.6 on my centOS 5 system and then I installed nltk.
Now I am running a certain python script and it gives me this error-
ImportError: No module named _sqlite3
Hi!
This mailing list is about developing Python itself, not about developing
*in* Python or debugging Python installations.
Try seeing help elsewhere, such as on the comp.lang.python newsgroup,
#python IRC channel on freenode, or other sources (check the wiki if you
need any others).
Thanks,
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
add relevant keywords to make it easier to find in searches
-0. Going through old issues just to make sure the keywords are right
seems wasteful.
ensure other fields in the
On 23/09/2010 13:11, Martin v. Löwis wrote:
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
Some people have requested to be assigned to issues. (Myself for
unittest, Ronald for Mac OS X issues etc.)
add relevant keywords
On Thu, Sep 23, 2010 at 6:11 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 23 Sep 2010 00:29:51 -0400
Fred Drake fdr...@acm.org wrote:
On Wed, Sep 22, 2010 at 10:38 PM, Brett Cannon br...@python.org wrote:
the first thing on the agenda is a complete rewrite of the developer
docs
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing
add relevant keywords to make it easier to find in searches
-0. Going through old issues just to make sure the keywords are right
seems wasteful.
Hard as it may be to believe, we do have (and are trying to cultivate)
people who want to contribute to Python and start by searching for
On 23/09/2010 13:28, Martin v. Löwis wrote:
add relevant keywords to make it easier to find in searches
-0. Going through old issues just to make sure the keywords are right
seems wasteful.
Hard as it may be to believe, we do have (and are trying to cultivate)
people who want to contribute
On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrou solip...@pitrou.net wrote:
The practicality argument of being able to edit those docs without
having to master a separate (pydotorg) workflow sounds quite strong to
me.
This is the key point for me. For developer controlled stuff, the
easiest
On Thursday 23 September 2010 08:36:47 Georg Brandl wrote:
This should be easy to do with a hg repo such as the test conversion one
on hg.python.org -- the activity extension already does the graphing,
and I'm sure it can easily be tweaked to your liking.
On Sep 23, 2010, at 08:40 AM, Georg Brandl wrote:
That's right. It is true that it isn't branch-specific information,
and that does cause a little bit of irritation for me too, but neither
is Misc/developers.txt or Misc/maintainers.rst.
Of course, we might consider a separate HG repository (I'm
2010/9/23 Barry Warsaw ba...@python.org:
On Sep 23, 2010, at 08:40 AM, Georg Brandl wrote:
That's right. It is true that it isn't branch-specific information,
and that does cause a little bit of irritation for me too, but neither
is Misc/developers.txt or Misc/maintainers.rst.
Of course, we
On Thu, Sep 23, 2010 at 10:01 AM, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 08:40 AM, Georg Brandl wrote:
That's right. It is true that it isn't branch-specific information,
and that does cause a little bit of irritation for me too, but neither
is Misc/developers.txt or
On Thu, 23 Sep 2010 23:35:02 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrou solip...@pitrou.net wrote:
The practicality argument of being able to edit those docs without
having to master a separate (pydotorg) workflow sounds quite strong to
me.
On 23/09/2010 15:16, R. David Murray wrote:
On Thu, 23 Sep 2010 23:35:02 +1000, Nick Coghlanncogh...@gmail.com wrote:
On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrousolip...@pitrou.net wrote:
The practicality argument of being able to edit those docs without
having to master a separate
On Thu, 23 Sep 2010 10:16:01 -0400
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 23 Sep 2010 23:35:02 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Sep 23, 2010 at 8:11 PM, Antoine Pitrou solip...@pitrou.net wrote:
The practicality argument of being able to edit those docs
On Sep 23, 2010, at 10:16 AM, R. David Murray wrote:
I'd *much* rather edit rst files than futz with a web interface when
editing docs. The wiki also somehow feels less official.
There are dvcs-backed wikis, for example:
https://launchpad.net/wikkid
:)
I don't agree that the wiki feels less
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
-1 on wiki; wikis are where good information goes off to die.
Well, *all* documentation requires vigilance to remain relevant and current.
I'm sure you don't think the Python wiki is useless, right? ;)
-Barry
signature.asc
Description: PGP
On Sep 23, 2010, at 09:06 AM, Benjamin Peterson wrote:
Are any of our docs subject to release schedules?
I guess what I'm concerned about is this scenario:
You're a developer who has the source code to Python 3.1. You read the
in-tree docs to get a sense of how our development process works.
On Thu, Sep 23, 2010 at 10:35 AM, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
-1 on wiki; wikis are where good information goes off to die.
Well, *all* documentation requires vigilance to remain relevant and current.
I'm sure you don't think the
Am 23.09.2010 16:33, schrieb Barry Warsaw:
On Sep 23, 2010, at 10:16 AM, R. David Murray wrote:
I'd *much* rather edit rst files than futz with a web interface when
editing docs. The wiki also somehow feels less official.
There are dvcs-backed wikis, for example:
On Thu, Sep 23, 2010 at 7:35 AM, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
-1 on wiki; wikis are where good information goes off to die.
Well, *all* documentation requires vigilance to remain relevant and current.
I'm sure you don't think the
On Sep 23, 2010, at 10:43 AM, Jesse Noller wrote:
On Thu, Sep 23, 2010 at 10:35 AM, Barry Warsaw ba...@python.org
wrote:
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
-1 on wiki; wikis are where good information goes off to die.
Well, *all* documentation requires vigilance to remain
On Thu, Sep 23, 2010 at 7:47 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 23.09.2010 16:33, schrieb Barry Warsaw:
On Sep 23, 2010, at 10:16 AM, R. David Murray wrote:
I'd *much* rather edit rst files than futz with a web interface when
editing docs. The wiki also somehow feels less
On Thu, Sep 23, 2010 at 10:53 AM, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 10:43 AM, Jesse Noller wrote:
On Thu, Sep 23, 2010 at 10:35 AM, Barry Warsaw ba...@python.org
wrote:
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
-1 on wiki; wikis are where good information goes
On Thu, Sep 23, 2010 at 16:56, Guido van Rossum gu...@python.org wrote:
I want to believe your theory (since I also have a feeling that some
wiki pages feel less trustworthy than others) but my own use of
Wikipedia makes me skeptical that this is all there is -- on many
pages on important
On Thu, 23 Sep 2010 10:53:55 -0400
Barry Warsaw ba...@python.org wrote:
Of course, if the consensus is that wikis are just a waste of time and do more
harm than good, then we should shut ours down. (I don't agree it is though.)
I don't think they are a waste of time. However, as you and
There's no reason it *has* to be useless though. The Moin developer now has
shell access, so if there are technical problems with wiki, like its theme,
performance, or lack of features, we can get those fixed. If it's the content
or organization that needs improvement, then we can recruit
Hello All,
I am new to this list, but I have been lurking around getting a feel for the
environment and processes. I had some discussion yesterday about the
developer documentation as well, since it’s what I do professionally. I am a
technical writer but also work in the web development arena
I have to agree with Jesse. We have too many wiki pages that are so
out of date they're dangerous. They serve a purpose, and I think we
should have a wiki in addition to the official documentation. This
could be aggressively linked from it so people can comment on that
documentation -- a
On Thu, 23 Sep 2010 10:41:35 -0400, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 09:06 AM, Benjamin Peterson wrote:
Are any of our docs subject to release schedules?
I guess what I'm concerned about is this scenario:
You're a developer who has the source code to Python 3.1.
On Sep 23, 2010, at 05:32 PM, Antoine Pitrou wrote:
I don't think they are a waste of time. However, as you and Dirkjan
pointed out, a wiki needs some gardening to take care of its
structure and its presentation. The present Python wiki isn't very
inviting graphically, and its structure doesn't
On Thu, 23 Sep 2010 07:56:19 -0700, Guido van Rossum gu...@python.org wrote:
On Thu, Sep 23, 2010 at 7:47 AM, mar...@v.loewis.de wrote:
This impression comes along with the authority of potential authors.
If only the release manager can write a document, it is very official.
If any
On Sep 23, 2010, at 11:49 AM, R. David Murray wrote:
A separate repository would also be fine, IMO. If someone can find or
write the code to publish that repository to the appropriate location
automatically, we could presumably do this even before the rest of the
hg transition.
I'm not
On Thu, Sep 23, 2010 at 8:52 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I have to agree with Jesse. We have too many wiki pages that are so
out of date they're dangerous. They serve a purpose, and I think we
should have a wiki in addition to the official documentation. This
could be
On 9/23/2010 5:31 AM, Ender Wiggin wrote:
I think I have the skills to learn and fix the
code itself, but I don't have the time
and I am unfamiliar with the process of submitting patches and getting
Anyone can submit a patch at bugs.python.org. The process of getting one
approved includes
Am 23.09.2010 16:35, schrieb Barry Warsaw:
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
-1 on wiki; wikis are where good information goes off to die.
Well, *all* documentation requires vigilance to remain relevant and current.
I'm sure you don't think the Python wiki is useless, right?
Am 23.09.2010 16:47, schrieb Guido van Rossum:
On Thu, Sep 23, 2010 at 7:35 AM, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 10:06 AM, Jesse Noller wrote:
-1 on wiki; wikis are where good information goes off to die.
Well, *all* documentation requires vigilance to remain relevant
Am 23.09.2010 16:41, schrieb Barry Warsaw:
On Sep 23, 2010, at 09:06 AM, Benjamin Peterson wrote:
Are any of our docs subject to release schedules?
I guess what I'm concerned about is this scenario:
You're a developer who has the source code to Python 3.1. You read the
in-tree docs to
On Thu, 23 Sep 2010 11:57:19 -0400
Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 05:32 PM, Antoine Pitrou wrote:
I don't think they are a waste of time. However, as you and Dirkjan
pointed out, a wiki needs some gardening to take care of its
structure and its presentation. The
If we can recruit a bunch of somebodies who *do* care, then the wiki
would be much more useful. But I still don't want to edit the
dev docs there, if I have a choice :) There's a reason I stopped
updating the wiki as soon as I moved to a code repository.
I think that there are plenty
On 9/23/2010 3:18 AM, Martin v. Löwis wrote:
I personally think that the tracker fields and how they should be set is
of minor importance.
As of just now, if you were to wonder What (security) bugs are open for
2.5 and search on open 2.5 issues, you would get a list of 44 issues.
It is only
On 9/23/2010 8:11 AM, Martin v. Löwis wrote:
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
What I and Mark (that I know of) did in that respect was to assign doc
issues, including old issues reclassified as doc issues, to
Speaking as a frequent contributor of bug reports and an occasional
contributor of patches, I must say that I feel like status quo of the
tracker before Mark's work was discouraging. If there is a vast
collection of abandoned tickets, it gives me the strong impression
that my attempted
On 9/23/2010 7:41 AM, Barry Warsaw wrote:
Our development processes are*primarily* independent of Python version, so I
don't think they should be tied to our source tree, and our CPython source
tree at that. I suspect the version-dependent instructions will be minimal
and can be handled by
On 9/23/2010 1:44 PM, Terry Reedy wrote:
On 9/23/2010 8:11 AM, Martin v. Löwis wrote:
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
What I and Mark (that I know of) did in that respect was to assign doc
issues, including
On Thu, 23 Sep 2010 11:50:26 -0600, Zooko O'Whielacronx zo...@zooko.com
wrote:
Also, I would like to point out that, not having read the other
traffic that this thread alludes to, either from earlier mailing list
threads or from IRC, I don't really understand what exactly Mark did
wrong. The
Antoine The present Python wiki isn't very inviting graphically, and
Antoine its structure doesn't look very thought out.
I imagine it can be made to look more like the rest of python.org without a
lot of trouble. As to the structure, like most wikis it quickly resembles a
bag-o-pages
Antoine Given that few or none of us seem to (want to) actively
Antoine contribute to the wiki, I'm afraid python-dev is not the place
Antoine to ask. Perhaps a call should be issued on c.l.py ...
It would be nice if you could actually send messages to the people who do
actually
Am 23.09.2010 19:22, schrieb Terry Reedy:
Asking every now and then is this still an issue, or setting
the version number, doesn't really advance the issue.
Numerous issues have been advanced by the questions I and Mark have
asked. Some were legitimately closed as out of date (the bug
On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw ba...@python.org wrote:
I certainly agree with that. So, how can we solve those problems? Radomir
has shell access now so perhaps we can ask him to make the Python wiki theme
more visually appealing. What roadblocks do people encounter when they
Le 23/09/2010 19:22, Terry Reedy a écrit :
As of just now, if you were to wonder What (security) bugs are open for
2.5 and search on open 2.5 issues, you would get a list of 44 issues.
It is only 44 instead of hundreds because of the work I and Mark have
done in the last 4 months. It it 44
On Thu, Sep 23, 2010 at 09:05, Barry Warsaw ba...@python.org wrote:
On Sep 23, 2010, at 11:49 AM, R. David Murray wrote:
A separate repository would also be fine, IMO. If someone can find or
write the code to publish that repository to the appropriate location
automatically, we could presumably
Asking every now and then is this still an issue, or setting
the version number, doesn't really advance the issue.
Setting Versions properly helps anyone searching for issues relevant to
a particular version. If having a field set properly does not matter,
then is should not be there. Are
On Thu, Sep 23, 2010 at 7:31 PM, Ender Wiggin wiggi...@gmail.com wrote:
Sorry for the late reply. I would really like to see this fixed.
Or we [...] deprecate binascii.(un)hexlify().
...
binascii is the legacy approach here, so if anything was to go, those
functions would be it
...
I'm
On 9/23/2010 3:50 PM, Georg Brandl wrote:
ISTM that the versions field is not very useful if the other fields are
filled accurately.
For example, feature requests almost always only belong to the current trunk.
Yes, for features that fall under the moratorium, the versions field would
be
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl g.bra...@gmx.net wrote:
Setting Versions properly helps anyone searching for issues relevant to
a particular version. If having a field set properly does not matter,
then is should not be there. Are you suggesting that Versions be deleted?
ISTM
On Fri, Sep 24, 2010 at 3:44 AM, Terry Reedy tjre...@udel.edu wrote:
On 9/23/2010 8:11 AM, Martin v. Löwis wrote:
make sure the issue is assigned to the right person if appropriate
-1. We typically don't assign issues to others.
What I and Mark (that I know of) did in that respect was to
On Fri, Sep 24, 2010 at 4:52 AM, s...@pobox.com wrote:
Antoine Given that few or none of us seem to (want to) actively
Antoine contribute to the wiki, I'm afraid python-dev is not the place
Antoine to ask. Perhaps a call should be issued on c.l.py ...
It would be nice if you could
On Fri, Sep 24, 2010 at 6:38 AM, brian.curtin
python-check...@python.org wrote:
Modified: python/branches/py3k/Lib/ntpath.py
==
--- python/branches/py3k/Lib/ntpath.py (original)
+++ python/branches/py3k/Lib/ntpath.py
With an admin team behind it, you can also make more use of ACLs to
flag certain parts of the wiki as official by making them only
editable by certain people (e.g. only devs, only the triage team, only
the wiki admins). But keeping those user lists up to date is itself
something that requires
On Thu, Sep 23, 2010 at 3:35 PM, Martin v. Löwis mar...@v.loewis.de wrote:
With an admin team behind it, you can also make more use of ACLs to
flag certain parts of the wiki as official by making them only
editable by certain people (e.g. only devs, only the triage team, only
the wiki admins).
On 9/23/2010 6:17 PM, Nick Coghlan wrote:
On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandlg.bra...@gmx.net wrote:
Setting Versions properly helps anyone searching for issues relevant to
a particular version. If having a field set properly does not matter,
then is should not be there. Are you
So if there turns out to be a major security hole or sever bug in 2.7,
then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of
branch?
In that case, would you just suggest everyone using 2.7 to jump to 3.x?
As long as a 2.x version is supported, filing bugs, branching and even
On Thu, Sep 23, 2010 at 17:30, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Sep 24, 2010 at 6:38 AM, brian.curtin
python-check...@python.org wrote:
Modified: python/branches/py3k/Lib/ntpath.py
==
---
On 9/23/2010 7:12 PM, dar...@ontrenet.com wrote:
So if there turns out to be a major security hole or sever bug in 2.7,
then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of
branch?
In that case, would you just suggest everyone using 2.7 to jump to 3.x?
As long as a 2.x version
[Forwarding to Python-Dev, as it's of some interest - jesse]
Call for proposals -- PyCon 2011 -- http://us.pycon.org/2011/
===
Proposal Due date: November 1st, 2010
PyCon is back! With a rocking new website, a great location and
more
On Fri, 24 Sep 2010 01:50:34 am Steven Elliott Jr wrote:
What I have done in various organizations has been to create a system
where an official repository is kept with all of the *official*
documentation and a way for users (developers) to submit their
proposals as to what they would like to
On Fri, 24 Sep 2010 01:42:03 am Martin v. Löwis wrote:
By nature (quick-quick), information is unorganized in a Wiki. This
is what wiki advocates cite as its main feature, and wiki opponents
as its main flaw.
I've never heard wiki advocates say that, and even a cursory glace at
wikis like
On Fri, 24 Sep 2010 01:57:19 am Barry Warsaw wrote:
I certainly agree with that. So, how can we solve those problems?
Radomir has shell access now so perhaps we can ask him to make the
Python wiki theme more visually appealing. What roadblocks do people
encounter when they want to help
Georg Brandl writes:
You should read my tweets more often :)
Now *there* is an innovation that never should have happened!
At least you're bringing up the average quality with every twit I mean
tweet.
___
Python-Dev mailing list
Am 24.09.2010 00:39, schrieb Guido van Rossum:
On Thu, Sep 23, 2010 at 3:35 PM, Martin v. Löwis mar...@v.loewis.de wrote:
With an admin team behind it, you can also make more use of ACLs to
flag certain parts of the wiki as official by making them only
editable by certain people (e.g. only
Martin v. Löwis writes:
I didn't say the field does not matter. I said adjusting it doesn't
advance the issue. Anybody *really* working on the issue might
choose to update it, or might choose to leave it incorrect when the
issue is going to be closed, anyway.
Yes, and we'd all like more
92 matches
Mail list logo
