--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.
Ether@SO here. Count me in. No particular area selected yet; still
reading through all the background material you have provided.
I'm quite keen to rid the docs of examples using indirect object syntax and
non-lexical filehandles, though :)
--
"Alliance: In international politics, the union of two thieves
who have their hands so deeply inserted in each other's pockets
that they cannot separately plunder a third." - Ambrose Bierce
. . . . .
Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
http://etheridge.ca/ PS++ PE-- b++ DI++++ e++ h(-)
Sadly, a lot of those will live on in the CPAN modules. I caught
someone adding such an example to a new CPAN module while at YAPC this
year. It took all of my self-control not to beat him into a bloody
pulp. I was unable to stop myself from saying "Jesus Christ! Why are
you doing that!".
If you are looking for an immediate task, [perlopquick][1] needs to be
fact checked and read for clarity. The clarity part is something we
need multiple people with different backgrounds doing.
[1]: http://github.com/cowens/perlopquick
I'm in too. I have way more things on my list of things that I'd like
to see happen than I could possibly handle. Some smaller ideas that I
wouldn't mind someone else stealing them from me, but that I'll
probably end up doing otherwise:
* Changing all uses of typeglob filehandles to lexical filehandles
(except where documenting open itself, obviously)
* Changing all uses of two argument open to three argument open
(except where documenting open itself)
I would really like the object oriented documentation to be taken into
the current century. Pretty much all of it was written in the 90s and
it's grossly out of date. I don't want to see @ISA anymore, seriously.
Not to mention there are some bugs in there. Some of the current
documentation is so bad that I think deleting it right now even before
we've written a replacement would be an improvement. This would be a
rather serious amount of work, it should probably be done by a small
group of people instead of one person.
Other ideas:
* perltrap should include modern languages like Python, Ruby and PHP.
This would be a lot more useful than Perl4 and awk.
* perlmodinstall should be made Build.PL aware
* perlipc should use IO::* instead of low level functions
I wish I had as much time as I have ideas though :-|
Leon Timmermans
me too (putting money where mouth is).
can't look now but I recall some inaccuracy I found in perlre ... (or
related) docs... and I'd like to improve the docs on use features
'state'; (note: not a regexpert)
both of those are pretty small though... so what could I work on that's bigger?
--
Caleb Cushing
Right now we need people reviewing [perlopquick][1] for mistakes and clarity.
[1]: http://github.com/cowens/perlopquick
Start reading the [perlopquick][1] descriptions for correctness and clarity.
[1]: http://github.com/cowens/perlopquick
Choose something from the short term goals list for now.
snip
> * Changing all uses of typeglob filehandles to lexical filehandles
> (except where documenting open itself, obviously)
> * Changing all uses of two argument open to three argument open
> (except where documenting open itself)
snip
These are part of the long term goal of cleaning up the examples in
the docs. The task itself is so large that my plan is to choose a
specific set of docs (preferable the most used ones like perlfunc) to
clean up for each release.
snip
> I would really like the object oriented documentation to be taken into
> the current century. Pretty much all of it was written in the 90s and
> it's grossly out of date. I don't want to see @ISA anymore, seriously.
> Not to mention there are some bugs in there. Some of the current
> documentation is so bad that I think deleting it right now even before
> we've written a replacement would be an improvement. This would be a
> rather serious amount of work, it should probably be done by a small
> group of people instead of one person.
snip
Yeah, I am trying to save as much of the current documentation as
possible (just to cut down on the workload), but somethings like the
OO stuff and perlre are just going to need complete overhauls.
snip
> Other ideas:
> * perltrap should include modern languages like Python, Ruby and PHP.
> This would be a lot more useful than Perl4 and awk.
> * perlmodinstall should be made Build.PL aware
> * perlipc should use IO::* instead of low level functions
snip
This is all good stuff to be adding to our long term goals.
snip
> I wish I had as much time as I have ideas though :-|
snip
It took me a year to get perlopquick to the point it is in now. I
figure it is going to take that long or longer for each of the other
documents that need massive overhauling as well. I am going for a
slow and steady approach. So long as we see some forward progress I
will be happy.
On Fri, Jul 2, 2010 at 7:54 PM, Chas. Owens <chas....@gmail.com> wrote:
> On Fri, Jul 2, 2010 at 14:35, Caleb Cushing <xenote...@gmail.com> wrote:
>> On Fri, Jul 2, 2010 at 10:03 AM, Chas. Owens <chas....@gmail.com> wrote:
>>> If you want to sign up for the Perl 5 Documentation Team, leave an
>>> email here or email me directly. If you know what you want to work on
>>> mention it, otherwise I will assign you a task.
>>>
>>
>> me too (putting money where mouth is).
>>
>> can't look now but I recall some inaccuracy I found in perlre ... (or
>> related) docs... and I'd like to improve the docs on use features
>> 'state'; (note: not a regexpert)
>>
>> both of those are pretty small though... so what could I work on that's bigger?
> snip
>
> Right now we need people reviewing [perlopquick][1] for mistakes and clarity.
>
> [1]: http://github.com/cowens/perlopquick
Although I'm not a native english speaker i would like to try to find
some time to give a hand to this project. I will have a look at
perlopquick, but do let me know if you have a more suitable task for
me. Thank you.
smash
At this time, the high priority list looks like
* reading perlopquick descriptions for correctness and clarity (this
needs as many people as possible)
* discussion of the proposed items in the list (this needs as many
people as possible)
* work on the logo/mascot
* first draft about how to document documentation changes added to perlpolicy
* finding a way to have one document that creates both a <DOC>.pod
and <DOC>ref.pod