From drupal at rocktreesky.com  Mon Mar  2 12:59:32 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Mon, 2 Mar 2009 07:59:32 -0500
Subject: [documentation] Drupalcon Sprint planning
Message-ID: <B0B7A233-FC31-41F7-BFCF-2D952254183B@rocktreesky.com>

Hey all,

I want to start focusing a bit more on what we will be doing on  
Saturday for the Doc sprint. There is a general post up at http://dc2009.drupalcon.org/session/documentation-sprint 
  and there is a Doodle to volunteer with helping at http://www.doodle.com/participation.html?pollId=nmuqmevpftx64bfz 
  (please sign up for slots, even if it is only an hour and others  
already have it marked; we'll need more than one or two people per  
slot :-)). Keep in mind that we will be doing the sprint online as  
well as in DC, so we will have IRC participants too.

I have created a page in the community initiatives section (http://drupal.org/node/388470 
) where we can fill out more details for sprint tasks, so please,  
please help fill that page out. We also need to make sure we review  
the New editorial style guide (http://drupal.org/node/377274) this  
week as I would like to have that pretty well nailed down so people  
can begin doing style reviews.

** If you wish to organize a "working group" on a particular issue  
during the sprint (e.g. theme docs, CVS docs, etc.), please add a  
child page to the Documentation sprint tasks page that explains what  
the group will focus on and any resources that can help people get up  
to speed. I will add working groups to the main Drupalcon sprint post  
later this week to make people aware of them.

Sorry that I can't get more written down at this point but I'm pretty  
tapped out with usability sprint work (which has been awesome yet  
exhausting). I really appreciate any help that the team can pull  
together. I think this will be the best sprint yet and we can really  
grab a lot of new contributors on Saturday if we get set up to help  
them.

Thanks
Addi

From darthsteven at gmail.com  Wed Mar  4 03:45:10 2009
From: darthsteven at gmail.com (Steven Jones)
Date: Wed, 4 Mar 2009 03:45:10 +0000
Subject: [documentation] Forms API handbook volunteer
In-Reply-To: <49A87408.2070501@8vue.com>
References: <1aebaaf0902252028o34d05cc9s48734cf188b8e8b4@mail.gmail.com>
	<f27865f50902260129xf6e8ccbve41a093e61184ce0@mail.gmail.com>
	<1aebaaf0902261138o4bfff716i2e679bb307b75b62@mail.gmail.com>
	<f27865f50902270520n6b79272sae71efd878730b7b@mail.gmail.com>
	<1aebaaf0902271321x317d7a92wb98f6ffda85af500@mail.gmail.com>
	<49A87408.2070501@8vue.com>
Message-ID: <f27865f50903031945r3a631c60qf01816f92007ee85@mail.gmail.com>

Hey everyone,

I'm wondering if anyone wants to meet up at Drupalcon to discuss this,
maybe at the documentation sprint?

The task of documenting FormAPI is a massive challenge, but I like the
idea of documenting examples, explaining the ways that the examples
work, and what they do.


Regards
Steven Jones
ComputerMinds ltd - Perfect Drupal Websites

Phone : 0121 288 0434
Mobile : 07951 270 026
http://www.computerminds.co.uk



2009/2/27 George <g at 8vue.com>:
> i'd like to suggest, examples. ie. a simple fapi array gives what type
> of element / form? ?a lot can be inferred from a simple example that
> would take many more words. and the example only needs to cover the
> point of the example, so, if you're discussing setting up a textfield,
> then no need to create the whole form, just that element.
>
> also system_settings_form is a great helper function ;)
>
> i also think the reference chart for fapi is a great resource once
> you've got the basics.
>
> thanks
>
> Sameer Siruguri wrote:
>> Steven,
>>
>> the feedback I have seen on different forums is not very detailed --
>> it's mostly of the sort, "I wish there were more
>> detailed/comprehensive documentation about forms."
>>
>> One proposal I have is that we start putting something out there and
>> see how people react to it, sort of a wiki style of doing it, where we
>> incorporate comments over time once there is something to comment to.
>>
>> Alternatively, we could canvas some of the people who have commented
>> on various Drupal related websites about the difficulty of getting
>> comprehensive documentation and ask what they are lacking.
>>
>> I think the spectrum will be fairly wide in terms of expertise people
>> who are looking for Forms docs already have, but I wouldn't be
>> surprised if many of them are newbies trying to get to grips with the
>> basics. As Nancy notes, there will also be people looking to do
>> dynamic elements and multi-stage forms.
>>
>> One idea I had was to first create the detailed description of
>> _everything_ the API does, and then write an FAQ for some of the
>> common-case tasks, that point to entries in the detailed description.
>>
>> Thoughts?
>> Sameer.
>>
>>
>> On 2/27/09, *Steven Jones* <darthsteven at gmail.com
>> <mailto:darthsteven at gmail.com>> wrote:
>>
>> ? ? Essentially, before launching into the massive effort of documenting
>> ? ? FormAPI, we should have the discussion: 'What should we document'.
>>
>> ? ? You mention: "lots of folks have been commenting on the lack of
>> ? ? something good". What are they after? Are they newbies getting to
>> ? ? grips with forms? Are they experienced developers wanting to do more?
>>
>> ? ? Can anyone suggest what the FormAPI docs should cover?
>>
>>
>> ? ? Regards
>> ? ? Steven Jones
>> ? ? ComputerMinds ltd - Perfect Drupal Websites
>>
>> ? ? Phone : 0121 288 0434
>> ? ? Mobile : 07951 270 026
>> ? ? http://www.computerminds.co.uk
>>
>>
>>
>> ? ? 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>> ? ? <mailto:siruguri at gmail.com>>:
>> ? ? > Steven,
>> ? ? >
>> ? ? > good to hear from you. I cannot make DrupalCon in DC, more's the
>> ? ? pity. I am
>> ? ? > interested in learning more about your views on how to properly
>> ? ? document the
>> ? ? > Forms API. Did you mean to say that the outline written by
>> ? ? Steven Peck is
>> ? ? > the one you have some doubts about? Or just the general style of the
>> ? ? > content?
>> ? ? >
>> ? ? > I am interested in getting content out there asap, lots of folks
>> ? ? have been
>> ? ? > commenting on the lack of something good. Personally, I think
>> ? ? having an
>> ? ? > explanation of the steps inside drupal_get_form (process,
>> ? ? prepare, alter,
>> ? ? > render, etc.) would be very useful, esp. for ninja developers.
>> ? ? It's easy to
>> ? ? > get things mixed up if you don't know the exact order in which
>> ? ? these steps
>> ? ? > are called, including the parts where weights get sorted out,
>> ? ? and when
>> ? ? > pre/post_render functions get called.
>> ? ? >
>> ? ? > I would love to discuss some of these over email, if that's
>> ? ? possible, or of
>> ? ? > course, to hear more about what you learn at DrupalCon.
>> ? ? >
>> ? ? > Cheers!
>> ? ? > Sameer.
>> ? ? >
>> ? ? > On 2/26/09, Steven Jones <darthsteven at gmail.com
>> ? ? <mailto:darthsteven at gmail.com>> wrote:
>> ? ? >>
>> ? ? >> Hi Sameer,
>> ? ? >>
>> ? ? >> I actually was just the last person to edit that page, the
>> ? ? content is
>> ? ? >> down to Steven Peck.
>> ? ? >>
>> ? ? >> In any case I'm not sure that documenting FormAPI like that is the
>> ? ? >> best way to go. Like you I've wanted to document FormAPI better
>> ? ? for a
>> ? ? >> while now, but I'm not sure the best way to approach it. Maybe we
>> ? ? >> could gather a few interested parties at Drupalcon D.C. and have a
>> ? ? >> little chat about the best way forward.
>> ? ? >>
>> ? ? >> Are the any other's who'd be interested in helping out with
>> ? ? FormAPI docs?
>> ? ? >>
>> ? ? >> Regards
>> ? ? >> Steven Jones
>> ? ? >> ComputerMinds ltd - Perfect Drupal Websites
>> ? ? >>
>> ? ? >> Phone : 0121 288 0434
>> ? ? >> Mobile : 07951 270 026
>> ? ? >> http://www.computerminds.co.uk
>> ? ? >>
>> ? ? >>
>> ? ? >>
>> ? ? >> 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>> ? ? <mailto:siruguri at gmail.com>>:
>> ? ? >>
>> ? ? >> > Hi,
>> ? ? >> >
>> ? ? >> > I have been interested in fleshing out, and collating, the
>> ? ? documentation
>> ? ? >> > for
>> ? ? >> > the Forms API for some time now, and recently got started on
>> ? ? writing out
>> ? ? >> > the
>> ? ? >> > material that would go under the headings that Steven Jones
>> ? ? wrote out on
>> ? ? >> > this page: http://drupal.org/node/204270 (Here's a page I
>> ? ? wrote, with
>> ? ? >> > one
>> ? ? >> > child: http://drupal.org/node/384120)
>> ? ? >> >
>> ? ? >> > Here's the problem I ran into: After writing some pages down, I
>> ? ? >> > sheepishly
>> ? ? >> > realized that some material already existed as child pages.
>> ? ? But I don't
>> ? ? >> > have
>> ? ? >> > edit permissions to the top level of those child pages, which
>> ? ? makes it
>> ? ? >> > hard
>> ? ? >> > to incorporate some of my changes and esp. to consolidate all the
>> ? ? >> > material
>> ? ? >> > at the top level.
>> ? ? >> >
>> ? ? >> > Here are some solutions: I could go ahead and build out all
>> ? ? the material
>> ? ? >> > and
>> ? ? >> > then propose a consolidation. I could build it on my own
>> ? ? website and
>> ? ? >> > find
>> ? ? >> > some way to export the book to be imported into Drupal.org. I
>> ? ? could have
>> ? ? >> > access to the top level pages. I could do something during
>> ? ? DrupalCon.
>> ? ? >> >
>> ? ? >> > I am open to suggestions. Thanks!
>> ? ? >> > Sameer.
>> ? ? >> >
>> ? ? >> >
>> ? ? >>
>> ? ? >> > --
>> ? ? >> > Pending work: http://drupal.org/project/issues/documentation/
>> ? ? >> > List archives: http://lists.drupal.org/pipermail/documentation/
>> ? ? >> >
>> ? ? >> --
>> ? ? >> Pending work: http://drupal.org/project/issues/documentation/
>> ? ? >> List archives: http://lists.drupal.org/pipermail/documentation/
>> ? ? >
>> ? ? >
>> ? ? > --
>> ? ? > Pending work: http://drupal.org/project/issues/documentation/
>> ? ? > List archives: http://lists.drupal.org/pipermail/documentation/
>> ? ? >
>> ? ? --
>> ? ? Pending work: http://drupal.org/project/issues/documentation/
>> ? ? List archives: http://lists.drupal.org/pipermail/documentation/
>>
>>
>> ------------------------------------------------------------------------
>>
>> --
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>

From g at 8vue.com  Wed Mar  4 09:26:08 2009
From: g at 8vue.com (George)
Date: Wed, 04 Mar 2009 10:26:08 +0100
Subject: [documentation] Forms API handbook volunteer
In-Reply-To: <f27865f50903031945r3a631c60qf01816f92007ee85@mail.gmail.com>
References: <1aebaaf0902252028o34d05cc9s48734cf188b8e8b4@mail.gmail.com>	<f27865f50902260129xf6e8ccbve41a093e61184ce0@mail.gmail.com>	<1aebaaf0902261138o4bfff716i2e679bb307b75b62@mail.gmail.com>	<f27865f50902270520n6b79272sae71efd878730b7b@mail.gmail.com>	<1aebaaf0902271321x317d7a92wb98f6ffda85af500@mail.gmail.com>	<49A87408.2070501@8vue.com>
	<f27865f50903031945r3a631c60qf01816f92007ee85@mail.gmail.com>
Message-ID: <49AE4930.6090308@8vue.com>

i'd like to suggest a simple starting outline for fapi

1/ intro - what is fapi, why not use html? security, consistency, etc

2 a/a basic input field - a description with example of basic textfield
2 b/properties of the textfield input (including #default_value)

3/ a simple form - putting the above example into a form, with a submit 
button. perhaps using system settings form and explaining why it's so cool!

4/ other input fields - pointing to the ref sheet, and also mentioning 
the other most used inputs and properties.
4 b/ buttons

5/ callbacks - outline of form building function, validation, submit for 
element and form
5 b/ drupal_get_form - how to use it in page callbacks for module dev
5c /example of simple module with formbuilder, form validation, element 
validation, form submit? (no db stuff, just using comments in the module 
to suggest like for the submit function // this is the action of the 
form, and we now know values are safe to work with, and can be inserted 
into the database, or acted upon

6/ what functions you shouldn't call directly

7/ ...



Steven Jones wrote:
> Hey everyone,
>
> I'm wondering if anyone wants to meet up at Drupalcon to discuss this,
> maybe at the documentation sprint?
>
> The task of documenting FormAPI is a massive challenge, but I like the
> idea of documenting examples, explaining the ways that the examples
> work, and what they do.
>
>
> Regards
> Steven Jones
> ComputerMinds ltd - Perfect Drupal Websites
>
> Phone : 0121 288 0434
> Mobile : 07951 270 026
> http://www.computerminds.co.uk
>
>
>
> 2009/2/27 George <g at 8vue.com>:
>   
>> i'd like to suggest, examples. ie. a simple fapi array gives what type
>> of element / form?  a lot can be inferred from a simple example that
>> would take many more words. and the example only needs to cover the
>> point of the example, so, if you're discussing setting up a textfield,
>> then no need to create the whole form, just that element.
>>
>> also system_settings_form is a great helper function ;)
>>
>> i also think the reference chart for fapi is a great resource once
>> you've got the basics.
>>
>> thanks
>>
>> Sameer Siruguri wrote:
>>     
>>> Steven,
>>>
>>> the feedback I have seen on different forums is not very detailed --
>>> it's mostly of the sort, "I wish there were more
>>> detailed/comprehensive documentation about forms."
>>>
>>> One proposal I have is that we start putting something out there and
>>> see how people react to it, sort of a wiki style of doing it, where we
>>> incorporate comments over time once there is something to comment to.
>>>
>>> Alternatively, we could canvas some of the people who have commented
>>> on various Drupal related websites about the difficulty of getting
>>> comprehensive documentation and ask what they are lacking.
>>>
>>> I think the spectrum will be fairly wide in terms of expertise people
>>> who are looking for Forms docs already have, but I wouldn't be
>>> surprised if many of them are newbies trying to get to grips with the
>>> basics. As Nancy notes, there will also be people looking to do
>>> dynamic elements and multi-stage forms.
>>>
>>> One idea I had was to first create the detailed description of
>>> _everything_ the API does, and then write an FAQ for some of the
>>> common-case tasks, that point to entries in the detailed description.
>>>
>>> Thoughts?
>>> Sameer.
>>>
>>>
>>> On 2/27/09, *Steven Jones* <darthsteven at gmail.com
>>> <mailto:darthsteven at gmail.com>> wrote:
>>>
>>>     Essentially, before launching into the massive effort of documenting
>>>     FormAPI, we should have the discussion: 'What should we document'.
>>>
>>>     You mention: "lots of folks have been commenting on the lack of
>>>     something good". What are they after? Are they newbies getting to
>>>     grips with forms? Are they experienced developers wanting to do more?
>>>
>>>     Can anyone suggest what the FormAPI docs should cover?
>>>
>>>
>>>     Regards
>>>     Steven Jones
>>>     ComputerMinds ltd - Perfect Drupal Websites
>>>
>>>     Phone : 0121 288 0434
>>>     Mobile : 07951 270 026
>>>     http://www.computerminds.co.uk
>>>
>>>
>>>
>>>     2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>     <mailto:siruguri at gmail.com>>:
>>>     > Steven,
>>>     >
>>>     > good to hear from you. I cannot make DrupalCon in DC, more's the
>>>     pity. I am
>>>     > interested in learning more about your views on how to properly
>>>     document the
>>>     > Forms API. Did you mean to say that the outline written by
>>>     Steven Peck is
>>>     > the one you have some doubts about? Or just the general style of the
>>>     > content?
>>>     >
>>>     > I am interested in getting content out there asap, lots of folks
>>>     have been
>>>     > commenting on the lack of something good. Personally, I think
>>>     having an
>>>     > explanation of the steps inside drupal_get_form (process,
>>>     prepare, alter,
>>>     > render, etc.) would be very useful, esp. for ninja developers.
>>>     It's easy to
>>>     > get things mixed up if you don't know the exact order in which
>>>     these steps
>>>     > are called, including the parts where weights get sorted out,
>>>     and when
>>>     > pre/post_render functions get called.
>>>     >
>>>     > I would love to discuss some of these over email, if that's
>>>     possible, or of
>>>     > course, to hear more about what you learn at DrupalCon.
>>>     >
>>>     > Cheers!
>>>     > Sameer.
>>>     >
>>>     > On 2/26/09, Steven Jones <darthsteven at gmail.com
>>>     <mailto:darthsteven at gmail.com>> wrote:
>>>     >>
>>>     >> Hi Sameer,
>>>     >>
>>>     >> I actually was just the last person to edit that page, the
>>>     content is
>>>     >> down to Steven Peck.
>>>     >>
>>>     >> In any case I'm not sure that documenting FormAPI like that is the
>>>     >> best way to go. Like you I've wanted to document FormAPI better
>>>     for a
>>>     >> while now, but I'm not sure the best way to approach it. Maybe we
>>>     >> could gather a few interested parties at Drupalcon D.C. and have a
>>>     >> little chat about the best way forward.
>>>     >>
>>>     >> Are the any other's who'd be interested in helping out with
>>>     FormAPI docs?
>>>     >>
>>>     >> Regards
>>>     >> Steven Jones
>>>     >> ComputerMinds ltd - Perfect Drupal Websites
>>>     >>
>>>     >> Phone : 0121 288 0434
>>>     >> Mobile : 07951 270 026
>>>     >> http://www.computerminds.co.uk
>>>     >>
>>>     >>
>>>     >>
>>>     >> 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>     <mailto:siruguri at gmail.com>>:
>>>     >>
>>>     >> > Hi,
>>>     >> >
>>>     >> > I have been interested in fleshing out, and collating, the
>>>     documentation
>>>     >> > for
>>>     >> > the Forms API for some time now, and recently got started on
>>>     writing out
>>>     >> > the
>>>     >> > material that would go under the headings that Steven Jones
>>>     wrote out on
>>>     >> > this page: http://drupal.org/node/204270 (Here's a page I
>>>     wrote, with
>>>     >> > one
>>>     >> > child: http://drupal.org/node/384120)
>>>     >> >
>>>     >> > Here's the problem I ran into: After writing some pages down, I
>>>     >> > sheepishly
>>>     >> > realized that some material already existed as child pages.
>>>     But I don't
>>>     >> > have
>>>     >> > edit permissions to the top level of those child pages, which
>>>     makes it
>>>     >> > hard
>>>     >> > to incorporate some of my changes and esp. to consolidate all the
>>>     >> > material
>>>     >> > at the top level.
>>>     >> >
>>>     >> > Here are some solutions: I could go ahead and build out all
>>>     the material
>>>     >> > and
>>>     >> > then propose a consolidation. I could build it on my own
>>>     website and
>>>     >> > find
>>>     >> > some way to export the book to be imported into Drupal.org. I
>>>     could have
>>>     >> > access to the top level pages. I could do something during
>>>     DrupalCon.
>>>     >> >
>>>     >> > I am open to suggestions. Thanks!
>>>     >> > Sameer.
>>>     >> >
>>>     >> >
>>>     >>
>>>     >> > --
>>>     >> > Pending work: http://drupal.org/project/issues/documentation/
>>>     >> > List archives: http://lists.drupal.org/pipermail/documentation/
>>>     >> >
>>>     >> --
>>>     >> Pending work: http://drupal.org/project/issues/documentation/
>>>     >> List archives: http://lists.drupal.org/pipermail/documentation/
>>>     >
>>>     >
>>>     > --
>>>     > Pending work: http://drupal.org/project/issues/documentation/
>>>     > List archives: http://lists.drupal.org/pipermail/documentation/
>>>     >
>>>     --
>>>     Pending work: http://drupal.org/project/issues/documentation/
>>>     List archives: http://lists.drupal.org/pipermail/documentation/
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> --
>>> Pending work: http://drupal.org/project/issues/documentation/
>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>       
>> --
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>>
>>     
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>   


From darthsteven at gmail.com  Thu Mar  5 15:24:03 2009
From: darthsteven at gmail.com (Steven Jones)
Date: Thu, 5 Mar 2009 15:24:03 +0000
Subject: [documentation] Forms API handbook volunteer
In-Reply-To: <49AE4930.6090308@8vue.com>
References: <1aebaaf0902252028o34d05cc9s48734cf188b8e8b4@mail.gmail.com>
	<f27865f50902260129xf6e8ccbve41a093e61184ce0@mail.gmail.com>
	<1aebaaf0902261138o4bfff716i2e679bb307b75b62@mail.gmail.com>
	<f27865f50902270520n6b79272sae71efd878730b7b@mail.gmail.com>
	<1aebaaf0902271321x317d7a92wb98f6ffda85af500@mail.gmail.com>
	<49A87408.2070501@8vue.com>
	<f27865f50903031945r3a631c60qf01816f92007ee85@mail.gmail.com>
	<49AE4930.6090308@8vue.com>
Message-ID: <f27865f50903050724q1dca8260h6cf7c13a0d6c465e@mail.gmail.com>

So maybe we need to organise the top level, so we'd have:

1. Form API
1.a  High level - why use FormAPI
1.b  Form API basics
1.c  Advanced Form API

1.a Would be long pages of prose, explaining the why and a little of the how.

1.b This might take the form of a series of well written tutorials,
showing the basics, explaining things like nested $form arrays.

1.c This could be the place to chuck the examples, 'here's how I did
this' kind of code. I think these have the lowest barriers to entry,
so people will be more likely to write these. No?


Regards
Steven Jones
ComputerMinds ltd - Perfect Drupal Websites

Phone : 0121 288 0434
Mobile : 07951 270 026
http://www.computerminds.co.uk



2009/3/4 George <g at 8vue.com>:
> i'd like to suggest a simple starting outline for fapi
>
> 1/ intro - what is fapi, why not use html? security, consistency, etc
>
> 2 a/a basic input field - a description with example of basic textfield
> 2 b/properties of the textfield input (including #default_value)
>
> 3/ a simple form - putting the above example into a form, with a submit
> button. perhaps using system settings form and explaining why it's so cool!
>
> 4/ other input fields - pointing to the ref sheet, and also mentioning
> the other most used inputs and properties.
> 4 b/ buttons
>
> 5/ callbacks - outline of form building function, validation, submit for
> element and form
> 5 b/ drupal_get_form - how to use it in page callbacks for module dev
> 5c /example of simple module with formbuilder, form validation, element
> validation, form submit? (no db stuff, just using comments in the module
> to suggest like for the submit function // this is the action of the
> form, and we now know values are safe to work with, and can be inserted
> into the database, or acted upon
>
> 6/ what functions you shouldn't call directly
>
> 7/ ...
>
>
>
> Steven Jones wrote:
>> Hey everyone,
>>
>> I'm wondering if anyone wants to meet up at Drupalcon to discuss this,
>> maybe at the documentation sprint?
>>
>> The task of documenting FormAPI is a massive challenge, but I like the
>> idea of documenting examples, explaining the ways that the examples
>> work, and what they do.
>>
>>
>> Regards
>> Steven Jones
>> ComputerMinds ltd - Perfect Drupal Websites
>>
>> Phone : 0121 288 0434
>> Mobile : 07951 270 026
>> http://www.computerminds.co.uk
>>
>>
>>
>> 2009/2/27 George <g at 8vue.com>:
>>
>>> i'd like to suggest, examples. ie. a simple fapi array gives what type
>>> of element / form? ?a lot can be inferred from a simple example that
>>> would take many more words. and the example only needs to cover the
>>> point of the example, so, if you're discussing setting up a textfield,
>>> then no need to create the whole form, just that element.
>>>
>>> also system_settings_form is a great helper function ;)
>>>
>>> i also think the reference chart for fapi is a great resource once
>>> you've got the basics.
>>>
>>> thanks
>>>
>>> Sameer Siruguri wrote:
>>>
>>>> Steven,
>>>>
>>>> the feedback I have seen on different forums is not very detailed --
>>>> it's mostly of the sort, "I wish there were more
>>>> detailed/comprehensive documentation about forms."
>>>>
>>>> One proposal I have is that we start putting something out there and
>>>> see how people react to it, sort of a wiki style of doing it, where we
>>>> incorporate comments over time once there is something to comment to.
>>>>
>>>> Alternatively, we could canvas some of the people who have commented
>>>> on various Drupal related websites about the difficulty of getting
>>>> comprehensive documentation and ask what they are lacking.
>>>>
>>>> I think the spectrum will be fairly wide in terms of expertise people
>>>> who are looking for Forms docs already have, but I wouldn't be
>>>> surprised if many of them are newbies trying to get to grips with the
>>>> basics. As Nancy notes, there will also be people looking to do
>>>> dynamic elements and multi-stage forms.
>>>>
>>>> One idea I had was to first create the detailed description of
>>>> _everything_ the API does, and then write an FAQ for some of the
>>>> common-case tasks, that point to entries in the detailed description.
>>>>
>>>> Thoughts?
>>>> Sameer.
>>>>
>>>>
>>>> On 2/27/09, *Steven Jones* <darthsteven at gmail.com
>>>> <mailto:darthsteven at gmail.com>> wrote:
>>>>
>>>> ? ? Essentially, before launching into the massive effort of documenting
>>>> ? ? FormAPI, we should have the discussion: 'What should we document'.
>>>>
>>>> ? ? You mention: "lots of folks have been commenting on the lack of
>>>> ? ? something good". What are they after? Are they newbies getting to
>>>> ? ? grips with forms? Are they experienced developers wanting to do more?
>>>>
>>>> ? ? Can anyone suggest what the FormAPI docs should cover?
>>>>
>>>>
>>>> ? ? Regards
>>>> ? ? Steven Jones
>>>> ? ? ComputerMinds ltd - Perfect Drupal Websites
>>>>
>>>> ? ? Phone : 0121 288 0434
>>>> ? ? Mobile : 07951 270 026
>>>> ? ? http://www.computerminds.co.uk
>>>>
>>>>
>>>>
>>>> ? ? 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>> ? ? <mailto:siruguri at gmail.com>>:
>>>> ? ? > Steven,
>>>> ? ? >
>>>> ? ? > good to hear from you. I cannot make DrupalCon in DC, more's the
>>>> ? ? pity. I am
>>>> ? ? > interested in learning more about your views on how to properly
>>>> ? ? document the
>>>> ? ? > Forms API. Did you mean to say that the outline written by
>>>> ? ? Steven Peck is
>>>> ? ? > the one you have some doubts about? Or just the general style of the
>>>> ? ? > content?
>>>> ? ? >
>>>> ? ? > I am interested in getting content out there asap, lots of folks
>>>> ? ? have been
>>>> ? ? > commenting on the lack of something good. Personally, I think
>>>> ? ? having an
>>>> ? ? > explanation of the steps inside drupal_get_form (process,
>>>> ? ? prepare, alter,
>>>> ? ? > render, etc.) would be very useful, esp. for ninja developers.
>>>> ? ? It's easy to
>>>> ? ? > get things mixed up if you don't know the exact order in which
>>>> ? ? these steps
>>>> ? ? > are called, including the parts where weights get sorted out,
>>>> ? ? and when
>>>> ? ? > pre/post_render functions get called.
>>>> ? ? >
>>>> ? ? > I would love to discuss some of these over email, if that's
>>>> ? ? possible, or of
>>>> ? ? > course, to hear more about what you learn at DrupalCon.
>>>> ? ? >
>>>> ? ? > Cheers!
>>>> ? ? > Sameer.
>>>> ? ? >
>>>> ? ? > On 2/26/09, Steven Jones <darthsteven at gmail.com
>>>> ? ? <mailto:darthsteven at gmail.com>> wrote:
>>>> ? ? >>
>>>> ? ? >> Hi Sameer,
>>>> ? ? >>
>>>> ? ? >> I actually was just the last person to edit that page, the
>>>> ? ? content is
>>>> ? ? >> down to Steven Peck.
>>>> ? ? >>
>>>> ? ? >> In any case I'm not sure that documenting FormAPI like that is the
>>>> ? ? >> best way to go. Like you I've wanted to document FormAPI better
>>>> ? ? for a
>>>> ? ? >> while now, but I'm not sure the best way to approach it. Maybe we
>>>> ? ? >> could gather a few interested parties at Drupalcon D.C. and have a
>>>> ? ? >> little chat about the best way forward.
>>>> ? ? >>
>>>> ? ? >> Are the any other's who'd be interested in helping out with
>>>> ? ? FormAPI docs?
>>>> ? ? >>
>>>> ? ? >> Regards
>>>> ? ? >> Steven Jones
>>>> ? ? >> ComputerMinds ltd - Perfect Drupal Websites
>>>> ? ? >>
>>>> ? ? >> Phone : 0121 288 0434
>>>> ? ? >> Mobile : 07951 270 026
>>>> ? ? >> http://www.computerminds.co.uk
>>>> ? ? >>
>>>> ? ? >>
>>>> ? ? >>
>>>> ? ? >> 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>> ? ? <mailto:siruguri at gmail.com>>:
>>>> ? ? >>
>>>> ? ? >> > Hi,
>>>> ? ? >> >
>>>> ? ? >> > I have been interested in fleshing out, and collating, the
>>>> ? ? documentation
>>>> ? ? >> > for
>>>> ? ? >> > the Forms API for some time now, and recently got started on
>>>> ? ? writing out
>>>> ? ? >> > the
>>>> ? ? >> > material that would go under the headings that Steven Jones
>>>> ? ? wrote out on
>>>> ? ? >> > this page: http://drupal.org/node/204270 (Here's a page I
>>>> ? ? wrote, with
>>>> ? ? >> > one
>>>> ? ? >> > child: http://drupal.org/node/384120)
>>>> ? ? >> >
>>>> ? ? >> > Here's the problem I ran into: After writing some pages down, I
>>>> ? ? >> > sheepishly
>>>> ? ? >> > realized that some material already existed as child pages.
>>>> ? ? But I don't
>>>> ? ? >> > have
>>>> ? ? >> > edit permissions to the top level of those child pages, which
>>>> ? ? makes it
>>>> ? ? >> > hard
>>>> ? ? >> > to incorporate some of my changes and esp. to consolidate all the
>>>> ? ? >> > material
>>>> ? ? >> > at the top level.
>>>> ? ? >> >
>>>> ? ? >> > Here are some solutions: I could go ahead and build out all
>>>> ? ? the material
>>>> ? ? >> > and
>>>> ? ? >> > then propose a consolidation. I could build it on my own
>>>> ? ? website and
>>>> ? ? >> > find
>>>> ? ? >> > some way to export the book to be imported into Drupal.org. I
>>>> ? ? could have
>>>> ? ? >> > access to the top level pages. I could do something during
>>>> ? ? DrupalCon.
>>>> ? ? >> >
>>>> ? ? >> > I am open to suggestions. Thanks!
>>>> ? ? >> > Sameer.
>>>> ? ? >> >
>>>> ? ? >> >
>>>> ? ? >>
>>>> ? ? >> > --
>>>> ? ? >> > Pending work: http://drupal.org/project/issues/documentation/
>>>> ? ? >> > List archives: http://lists.drupal.org/pipermail/documentation/
>>>> ? ? >> >
>>>> ? ? >> --
>>>> ? ? >> Pending work: http://drupal.org/project/issues/documentation/
>>>> ? ? >> List archives: http://lists.drupal.org/pipermail/documentation/
>>>> ? ? >
>>>> ? ? >
>>>> ? ? > --
>>>> ? ? > Pending work: http://drupal.org/project/issues/documentation/
>>>> ? ? > List archives: http://lists.drupal.org/pipermail/documentation/
>>>> ? ? >
>>>> ? ? --
>>>> ? ? Pending work: http://drupal.org/project/issues/documentation/
>>>> ? ? List archives: http://lists.drupal.org/pipermail/documentation/
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> --
>>>> Pending work: http://drupal.org/project/issues/documentation/
>>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>
>>> --
>>> Pending work: http://drupal.org/project/issues/documentation/
>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>
>>>
>> --
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>>
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>

From g at 8vue.com  Thu Mar  5 23:33:36 2009
From: g at 8vue.com (George)
Date: Fri, 06 Mar 2009 00:33:36 +0100
Subject: [documentation] Forms API handbook volunteer
In-Reply-To: <f27865f50903050724q1dca8260h6cf7c13a0d6c465e@mail.gmail.com>
References: <1aebaaf0902252028o34d05cc9s48734cf188b8e8b4@mail.gmail.com>	<f27865f50902260129xf6e8ccbve41a093e61184ce0@mail.gmail.com>	<1aebaaf0902261138o4bfff716i2e679bb307b75b62@mail.gmail.com>	<f27865f50902270520n6b79272sae71efd878730b7b@mail.gmail.com>	<1aebaaf0902271321x317d7a92wb98f6ffda85af500@mail.gmail.com>	<49A87408.2070501@8vue.com>	<f27865f50903031945r3a631c60qf01816f92007ee85@mail.gmail.com>	<49AE4930.6090308@8vue.com>
	<f27865f50903050724q1dca8260h6cf7c13a0d6c465e@mail.gmail.com>
Message-ID: <49B06150.9070709@8vue.com>

no, don't restrict just examples to one section, use them throughout as 
one may use a diagram. heck why not even compare an html form with a 
fapi form in the introduction? and don't over do the 'why use fapi' 
section, short and to the point.

verbosity is the enemy!

just my opinion!

Steven Jones wrote:
> So maybe we need to organise the top level, so we'd have:
>
> 1. Form API
> 1.a  High level - why use FormAPI
> 1.b  Form API basics
> 1.c  Advanced Form API
>
> 1.a Would be long pages of prose, explaining the why and a little of the how.
>
> 1.b This might take the form of a series of well written tutorials,
> showing the basics, explaining things like nested $form arrays.
>
> 1.c This could be the place to chuck the examples, 'here's how I did
> this' kind of code. I think these have the lowest barriers to entry,
> so people will be more likely to write these. No?
>
>
> Regards
> Steven Jones
> ComputerMinds ltd - Perfect Drupal Websites
>
> Phone : 0121 288 0434
> Mobile : 07951 270 026
> http://www.computerminds.co.uk
>
>
>
> 2009/3/4 George <g at 8vue.com>:
>   
>> i'd like to suggest a simple starting outline for fapi
>>
>> 1/ intro - what is fapi, why not use html? security, consistency, etc
>>
>> 2 a/a basic input field - a description with example of basic textfield
>> 2 b/properties of the textfield input (including #default_value)
>>
>> 3/ a simple form - putting the above example into a form, with a submit
>> button. perhaps using system settings form and explaining why it's so cool!
>>
>> 4/ other input fields - pointing to the ref sheet, and also mentioning
>> the other most used inputs and properties.
>> 4 b/ buttons
>>
>> 5/ callbacks - outline of form building function, validation, submit for
>> element and form
>> 5 b/ drupal_get_form - how to use it in page callbacks for module dev
>> 5c /example of simple module with formbuilder, form validation, element
>> validation, form submit? (no db stuff, just using comments in the module
>> to suggest like for the submit function // this is the action of the
>> form, and we now know values are safe to work with, and can be inserted
>> into the database, or acted upon
>>
>> 6/ what functions you shouldn't call directly
>>
>> 7/ ...
>>
>>
>>
>> Steven Jones wrote:
>>     
>>> Hey everyone,
>>>
>>> I'm wondering if anyone wants to meet up at Drupalcon to discuss this,
>>> maybe at the documentation sprint?
>>>
>>> The task of documenting FormAPI is a massive challenge, but I like the
>>> idea of documenting examples, explaining the ways that the examples
>>> work, and what they do.
>>>
>>>
>>> Regards
>>> Steven Jones
>>> ComputerMinds ltd - Perfect Drupal Websites
>>>
>>> Phone : 0121 288 0434
>>> Mobile : 07951 270 026
>>> http://www.computerminds.co.uk
>>>
>>>
>>>
>>> 2009/2/27 George <g at 8vue.com>:
>>>
>>>       
>>>> i'd like to suggest, examples. ie. a simple fapi array gives what type
>>>> of element / form?  a lot can be inferred from a simple example that
>>>> would take many more words. and the example only needs to cover the
>>>> point of the example, so, if you're discussing setting up a textfield,
>>>> then no need to create the whole form, just that element.
>>>>
>>>> also system_settings_form is a great helper function ;)
>>>>
>>>> i also think the reference chart for fapi is a great resource once
>>>> you've got the basics.
>>>>
>>>> thanks
>>>>
>>>> Sameer Siruguri wrote:
>>>>
>>>>         
>>>>> Steven,
>>>>>
>>>>> the feedback I have seen on different forums is not very detailed --
>>>>> it's mostly of the sort, "I wish there were more
>>>>> detailed/comprehensive documentation about forms."
>>>>>
>>>>> One proposal I have is that we start putting something out there and
>>>>> see how people react to it, sort of a wiki style of doing it, where we
>>>>> incorporate comments over time once there is something to comment to.
>>>>>
>>>>> Alternatively, we could canvas some of the people who have commented
>>>>> on various Drupal related websites about the difficulty of getting
>>>>> comprehensive documentation and ask what they are lacking.
>>>>>
>>>>> I think the spectrum will be fairly wide in terms of expertise people
>>>>> who are looking for Forms docs already have, but I wouldn't be
>>>>> surprised if many of them are newbies trying to get to grips with the
>>>>> basics. As Nancy notes, there will also be people looking to do
>>>>> dynamic elements and multi-stage forms.
>>>>>
>>>>> One idea I had was to first create the detailed description of
>>>>> _everything_ the API does, and then write an FAQ for some of the
>>>>> common-case tasks, that point to entries in the detailed description.
>>>>>
>>>>> Thoughts?
>>>>> Sameer.
>>>>>
>>>>>
>>>>> On 2/27/09, *Steven Jones* <darthsteven at gmail.com
>>>>> <mailto:darthsteven at gmail.com>> wrote:
>>>>>
>>>>>     Essentially, before launching into the massive effort of documenting
>>>>>     FormAPI, we should have the discussion: 'What should we document'.
>>>>>
>>>>>     You mention: "lots of folks have been commenting on the lack of
>>>>>     something good". What are they after? Are they newbies getting to
>>>>>     grips with forms? Are they experienced developers wanting to do more?
>>>>>
>>>>>     Can anyone suggest what the FormAPI docs should cover?
>>>>>
>>>>>
>>>>>     Regards
>>>>>     Steven Jones
>>>>>     ComputerMinds ltd - Perfect Drupal Websites
>>>>>
>>>>>     Phone : 0121 288 0434
>>>>>     Mobile : 07951 270 026
>>>>>     http://www.computerminds.co.uk
>>>>>
>>>>>
>>>>>
>>>>>     2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>>>     <mailto:siruguri at gmail.com>>:
>>>>>     > Steven,
>>>>>     >
>>>>>     > good to hear from you. I cannot make DrupalCon in DC, more's the
>>>>>     pity. I am
>>>>>     > interested in learning more about your views on how to properly
>>>>>     document the
>>>>>     > Forms API. Did you mean to say that the outline written by
>>>>>     Steven Peck is
>>>>>     > the one you have some doubts about? Or just the general style of the
>>>>>     > content?
>>>>>     >
>>>>>     > I am interested in getting content out there asap, lots of folks
>>>>>     have been
>>>>>     > commenting on the lack of something good. Personally, I think
>>>>>     having an
>>>>>     > explanation of the steps inside drupal_get_form (process,
>>>>>     prepare, alter,
>>>>>     > render, etc.) would be very useful, esp. for ninja developers.
>>>>>     It's easy to
>>>>>     > get things mixed up if you don't know the exact order in which
>>>>>     these steps
>>>>>     > are called, including the parts where weights get sorted out,
>>>>>     and when
>>>>>     > pre/post_render functions get called.
>>>>>     >
>>>>>     > I would love to discuss some of these over email, if that's
>>>>>     possible, or of
>>>>>     > course, to hear more about what you learn at DrupalCon.
>>>>>     >
>>>>>     > Cheers!
>>>>>     > Sameer.
>>>>>     >
>>>>>     > On 2/26/09, Steven Jones <darthsteven at gmail.com
>>>>>     <mailto:darthsteven at gmail.com>> wrote:
>>>>>     >>
>>>>>     >> Hi Sameer,
>>>>>     >>
>>>>>     >> I actually was just the last person to edit that page, the
>>>>>     content is
>>>>>     >> down to Steven Peck.
>>>>>     >>
>>>>>     >> In any case I'm not sure that documenting FormAPI like that is the
>>>>>     >> best way to go. Like you I've wanted to document FormAPI better
>>>>>     for a
>>>>>     >> while now, but I'm not sure the best way to approach it. Maybe we
>>>>>     >> could gather a few interested parties at Drupalcon D.C. and have a
>>>>>     >> little chat about the best way forward.
>>>>>     >>
>>>>>     >> Are the any other's who'd be interested in helping out with
>>>>>     FormAPI docs?
>>>>>     >>
>>>>>     >> Regards
>>>>>     >> Steven Jones
>>>>>     >> ComputerMinds ltd - Perfect Drupal Websites
>>>>>     >>
>>>>>     >> Phone : 0121 288 0434
>>>>>     >> Mobile : 07951 270 026
>>>>>     >> http://www.computerminds.co.uk
>>>>>     >>
>>>>>     >>
>>>>>     >>
>>>>>     >> 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>>>     <mailto:siruguri at gmail.com>>:
>>>>>     >>
>>>>>     >> > Hi,
>>>>>     >> >
>>>>>     >> > I have been interested in fleshing out, and collating, the
>>>>>     documentation
>>>>>     >> > for
>>>>>     >> > the Forms API for some time now, and recently got started on
>>>>>     writing out
>>>>>     >> > the
>>>>>     >> > material that would go under the headings that Steven Jones
>>>>>     wrote out on
>>>>>     >> > this page: http://drupal.org/node/204270 (Here's a page I
>>>>>     wrote, with
>>>>>     >> > one
>>>>>     >> > child: http://drupal.org/node/384120)
>>>>>     >> >
>>>>>     >> > Here's the problem I ran into: After writing some pages down, I
>>>>>     >> > sheepishly
>>>>>     >> > realized that some material already existed as child pages.
>>>>>     But I don't
>>>>>     >> > have
>>>>>     >> > edit permissions to the top level of those child pages, which
>>>>>     makes it
>>>>>     >> > hard
>>>>>     >> > to incorporate some of my changes and esp. to consolidate all the
>>>>>     >> > material
>>>>>     >> > at the top level.
>>>>>     >> >
>>>>>     >> > Here are some solutions: I could go ahead and build out all
>>>>>     the material
>>>>>     >> > and
>>>>>     >> > then propose a consolidation. I could build it on my own
>>>>>     website and
>>>>>     >> > find
>>>>>     >> > some way to export the book to be imported into Drupal.org. I
>>>>>     could have
>>>>>     >> > access to the top level pages. I could do something during
>>>>>     DrupalCon.
>>>>>     >> >
>>>>>     >> > I am open to suggestions. Thanks!
>>>>>     >> > Sameer.
>>>>>     >> >
>>>>>     >> >
>>>>>     >>
>>>>>     >> > --
>>>>>     >> > Pending work: http://drupal.org/project/issues/documentation/
>>>>>     >> > List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>     >> >
>>>>>     >> --
>>>>>     >> Pending work: http://drupal.org/project/issues/documentation/
>>>>>     >> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>     >
>>>>>     >
>>>>>     > --
>>>>>     > Pending work: http://drupal.org/project/issues/documentation/
>>>>>     > List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>     >
>>>>>     --
>>>>>     Pending work: http://drupal.org/project/issues/documentation/
>>>>>     List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> --
>>>>> Pending work: http://drupal.org/project/issues/documentation/
>>>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>
>>>>>           
>>>> --
>>>> Pending work: http://drupal.org/project/issues/documentation/
>>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>
>>>>
>>>>         
>>> --
>>> Pending work: http://drupal.org/project/issues/documentation/
>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>
>>>       
>> --
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>>
>>     
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>   


From darthsteven at gmail.com  Fri Mar  6 14:07:57 2009
From: darthsteven at gmail.com (Steven Jones)
Date: Fri, 6 Mar 2009 14:07:57 +0000
Subject: [documentation] Forms API handbook volunteer
In-Reply-To: <49B06150.9070709@8vue.com>
References: <1aebaaf0902252028o34d05cc9s48734cf188b8e8b4@mail.gmail.com>
	<f27865f50902260129xf6e8ccbve41a093e61184ce0@mail.gmail.com>
	<1aebaaf0902261138o4bfff716i2e679bb307b75b62@mail.gmail.com>
	<f27865f50902270520n6b79272sae71efd878730b7b@mail.gmail.com>
	<1aebaaf0902271321x317d7a92wb98f6ffda85af500@mail.gmail.com>
	<49A87408.2070501@8vue.com>
	<f27865f50903031945r3a631c60qf01816f92007ee85@mail.gmail.com>
	<49AE4930.6090308@8vue.com>
	<f27865f50903050724q1dca8260h6cf7c13a0d6c465e@mail.gmail.com>
	<49B06150.9070709@8vue.com>
Message-ID: <f27865f50903060607g1f5a017cwbd58b03137c8f037@mail.gmail.com>

George, don't hear me wrong! I'm not saying that we shouldn't use
examples in the other sections, but rather the last section should be
example driven. I.e. Each child page would be an example of some
specific thing using FormAPI.

The other sections could and should use examples, but would be focused
of explaining some specific portion of FormAPI, possibly using an
example.

Regards
Steven Jones
ComputerMinds ltd - Perfect Drupal Websites

Phone : 0121 288 0434
Mobile : 07951 270 026
http://www.computerminds.co.uk



2009/3/5 George <g at 8vue.com>:
> no, don't restrict just examples to one section, use them throughout as
> one may use a diagram. heck why not even compare an html form with a
> fapi form in the introduction? and don't over do the 'why use fapi'
> section, short and to the point.
>
> verbosity is the enemy!
>
> just my opinion!
>
> Steven Jones wrote:
>> So maybe we need to organise the top level, so we'd have:
>>
>> 1. Form API
>> 1.a ?High level - why use FormAPI
>> 1.b ?Form API basics
>> 1.c ?Advanced Form API
>>
>> 1.a Would be long pages of prose, explaining the why and a little of the how.
>>
>> 1.b This might take the form of a series of well written tutorials,
>> showing the basics, explaining things like nested $form arrays.
>>
>> 1.c This could be the place to chuck the examples, 'here's how I did
>> this' kind of code. I think these have the lowest barriers to entry,
>> so people will be more likely to write these. No?
>>
>>
>> Regards
>> Steven Jones
>> ComputerMinds ltd - Perfect Drupal Websites
>>
>> Phone : 0121 288 0434
>> Mobile : 07951 270 026
>> http://www.computerminds.co.uk
>>
>>
>>
>> 2009/3/4 George <g at 8vue.com>:
>>
>>> i'd like to suggest a simple starting outline for fapi
>>>
>>> 1/ intro - what is fapi, why not use html? security, consistency, etc
>>>
>>> 2 a/a basic input field - a description with example of basic textfield
>>> 2 b/properties of the textfield input (including #default_value)
>>>
>>> 3/ a simple form - putting the above example into a form, with a submit
>>> button. perhaps using system settings form and explaining why it's so cool!
>>>
>>> 4/ other input fields - pointing to the ref sheet, and also mentioning
>>> the other most used inputs and properties.
>>> 4 b/ buttons
>>>
>>> 5/ callbacks - outline of form building function, validation, submit for
>>> element and form
>>> 5 b/ drupal_get_form - how to use it in page callbacks for module dev
>>> 5c /example of simple module with formbuilder, form validation, element
>>> validation, form submit? (no db stuff, just using comments in the module
>>> to suggest like for the submit function // this is the action of the
>>> form, and we now know values are safe to work with, and can be inserted
>>> into the database, or acted upon
>>>
>>> 6/ what functions you shouldn't call directly
>>>
>>> 7/ ...
>>>
>>>
>>>
>>> Steven Jones wrote:
>>>
>>>> Hey everyone,
>>>>
>>>> I'm wondering if anyone wants to meet up at Drupalcon to discuss this,
>>>> maybe at the documentation sprint?
>>>>
>>>> The task of documenting FormAPI is a massive challenge, but I like the
>>>> idea of documenting examples, explaining the ways that the examples
>>>> work, and what they do.
>>>>
>>>>
>>>> Regards
>>>> Steven Jones
>>>> ComputerMinds ltd - Perfect Drupal Websites
>>>>
>>>> Phone : 0121 288 0434
>>>> Mobile : 07951 270 026
>>>> http://www.computerminds.co.uk
>>>>
>>>>
>>>>
>>>> 2009/2/27 George <g at 8vue.com>:
>>>>
>>>>
>>>>> i'd like to suggest, examples. ie. a simple fapi array gives what type
>>>>> of element / form? ?a lot can be inferred from a simple example that
>>>>> would take many more words. and the example only needs to cover the
>>>>> point of the example, so, if you're discussing setting up a textfield,
>>>>> then no need to create the whole form, just that element.
>>>>>
>>>>> also system_settings_form is a great helper function ;)
>>>>>
>>>>> i also think the reference chart for fapi is a great resource once
>>>>> you've got the basics.
>>>>>
>>>>> thanks
>>>>>
>>>>> Sameer Siruguri wrote:
>>>>>
>>>>>
>>>>>> Steven,
>>>>>>
>>>>>> the feedback I have seen on different forums is not very detailed --
>>>>>> it's mostly of the sort, "I wish there were more
>>>>>> detailed/comprehensive documentation about forms."
>>>>>>
>>>>>> One proposal I have is that we start putting something out there and
>>>>>> see how people react to it, sort of a wiki style of doing it, where we
>>>>>> incorporate comments over time once there is something to comment to.
>>>>>>
>>>>>> Alternatively, we could canvas some of the people who have commented
>>>>>> on various Drupal related websites about the difficulty of getting
>>>>>> comprehensive documentation and ask what they are lacking.
>>>>>>
>>>>>> I think the spectrum will be fairly wide in terms of expertise people
>>>>>> who are looking for Forms docs already have, but I wouldn't be
>>>>>> surprised if many of them are newbies trying to get to grips with the
>>>>>> basics. As Nancy notes, there will also be people looking to do
>>>>>> dynamic elements and multi-stage forms.
>>>>>>
>>>>>> One idea I had was to first create the detailed description of
>>>>>> _everything_ the API does, and then write an FAQ for some of the
>>>>>> common-case tasks, that point to entries in the detailed description.
>>>>>>
>>>>>> Thoughts?
>>>>>> Sameer.
>>>>>>
>>>>>>
>>>>>> On 2/27/09, *Steven Jones* <darthsteven at gmail.com
>>>>>> <mailto:darthsteven at gmail.com>> wrote:
>>>>>>
>>>>>> ? ? Essentially, before launching into the massive effort of documenting
>>>>>> ? ? FormAPI, we should have the discussion: 'What should we document'.
>>>>>>
>>>>>> ? ? You mention: "lots of folks have been commenting on the lack of
>>>>>> ? ? something good". What are they after? Are they newbies getting to
>>>>>> ? ? grips with forms? Are they experienced developers wanting to do more?
>>>>>>
>>>>>> ? ? Can anyone suggest what the FormAPI docs should cover?
>>>>>>
>>>>>>
>>>>>> ? ? Regards
>>>>>> ? ? Steven Jones
>>>>>> ? ? ComputerMinds ltd - Perfect Drupal Websites
>>>>>>
>>>>>> ? ? Phone : 0121 288 0434
>>>>>> ? ? Mobile : 07951 270 026
>>>>>> ? ? http://www.computerminds.co.uk
>>>>>>
>>>>>>
>>>>>>
>>>>>> ? ? 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>>>> ? ? <mailto:siruguri at gmail.com>>:
>>>>>> ? ? > Steven,
>>>>>> ? ? >
>>>>>> ? ? > good to hear from you. I cannot make DrupalCon in DC, more's the
>>>>>> ? ? pity. I am
>>>>>> ? ? > interested in learning more about your views on how to properly
>>>>>> ? ? document the
>>>>>> ? ? > Forms API. Did you mean to say that the outline written by
>>>>>> ? ? Steven Peck is
>>>>>> ? ? > the one you have some doubts about? Or just the general style of the
>>>>>> ? ? > content?
>>>>>> ? ? >
>>>>>> ? ? > I am interested in getting content out there asap, lots of folks
>>>>>> ? ? have been
>>>>>> ? ? > commenting on the lack of something good. Personally, I think
>>>>>> ? ? having an
>>>>>> ? ? > explanation of the steps inside drupal_get_form (process,
>>>>>> ? ? prepare, alter,
>>>>>> ? ? > render, etc.) would be very useful, esp. for ninja developers.
>>>>>> ? ? It's easy to
>>>>>> ? ? > get things mixed up if you don't know the exact order in which
>>>>>> ? ? these steps
>>>>>> ? ? > are called, including the parts where weights get sorted out,
>>>>>> ? ? and when
>>>>>> ? ? > pre/post_render functions get called.
>>>>>> ? ? >
>>>>>> ? ? > I would love to discuss some of these over email, if that's
>>>>>> ? ? possible, or of
>>>>>> ? ? > course, to hear more about what you learn at DrupalCon.
>>>>>> ? ? >
>>>>>> ? ? > Cheers!
>>>>>> ? ? > Sameer.
>>>>>> ? ? >
>>>>>> ? ? > On 2/26/09, Steven Jones <darthsteven at gmail.com
>>>>>> ? ? <mailto:darthsteven at gmail.com>> wrote:
>>>>>> ? ? >>
>>>>>> ? ? >> Hi Sameer,
>>>>>> ? ? >>
>>>>>> ? ? >> I actually was just the last person to edit that page, the
>>>>>> ? ? content is
>>>>>> ? ? >> down to Steven Peck.
>>>>>> ? ? >>
>>>>>> ? ? >> In any case I'm not sure that documenting FormAPI like that is the
>>>>>> ? ? >> best way to go. Like you I've wanted to document FormAPI better
>>>>>> ? ? for a
>>>>>> ? ? >> while now, but I'm not sure the best way to approach it. Maybe we
>>>>>> ? ? >> could gather a few interested parties at Drupalcon D.C. and have a
>>>>>> ? ? >> little chat about the best way forward.
>>>>>> ? ? >>
>>>>>> ? ? >> Are the any other's who'd be interested in helping out with
>>>>>> ? ? FormAPI docs?
>>>>>> ? ? >>
>>>>>> ? ? >> Regards
>>>>>> ? ? >> Steven Jones
>>>>>> ? ? >> ComputerMinds ltd - Perfect Drupal Websites
>>>>>> ? ? >>
>>>>>> ? ? >> Phone : 0121 288 0434
>>>>>> ? ? >> Mobile : 07951 270 026
>>>>>> ? ? >> http://www.computerminds.co.uk
>>>>>> ? ? >>
>>>>>> ? ? >>
>>>>>> ? ? >>
>>>>>> ? ? >> 2009/2/26 Sameer Siruguri <siruguri at gmail.com
>>>>>> ? ? <mailto:siruguri at gmail.com>>:
>>>>>> ? ? >>
>>>>>> ? ? >> > Hi,
>>>>>> ? ? >> >
>>>>>> ? ? >> > I have been interested in fleshing out, and collating, the
>>>>>> ? ? documentation
>>>>>> ? ? >> > for
>>>>>> ? ? >> > the Forms API for some time now, and recently got started on
>>>>>> ? ? writing out
>>>>>> ? ? >> > the
>>>>>> ? ? >> > material that would go under the headings that Steven Jones
>>>>>> ? ? wrote out on
>>>>>> ? ? >> > this page: http://drupal.org/node/204270 (Here's a page I
>>>>>> ? ? wrote, with
>>>>>> ? ? >> > one
>>>>>> ? ? >> > child: http://drupal.org/node/384120)
>>>>>> ? ? >> >
>>>>>> ? ? >> > Here's the problem I ran into: After writing some pages down, I
>>>>>> ? ? >> > sheepishly
>>>>>> ? ? >> > realized that some material already existed as child pages.
>>>>>> ? ? But I don't
>>>>>> ? ? >> > have
>>>>>> ? ? >> > edit permissions to the top level of those child pages, which
>>>>>> ? ? makes it
>>>>>> ? ? >> > hard
>>>>>> ? ? >> > to incorporate some of my changes and esp. to consolidate all the
>>>>>> ? ? >> > material
>>>>>> ? ? >> > at the top level.
>>>>>> ? ? >> >
>>>>>> ? ? >> > Here are some solutions: I could go ahead and build out all
>>>>>> ? ? the material
>>>>>> ? ? >> > and
>>>>>> ? ? >> > then propose a consolidation. I could build it on my own
>>>>>> ? ? website and
>>>>>> ? ? >> > find
>>>>>> ? ? >> > some way to export the book to be imported into Drupal.org. I
>>>>>> ? ? could have
>>>>>> ? ? >> > access to the top level pages. I could do something during
>>>>>> ? ? DrupalCon.
>>>>>> ? ? >> >
>>>>>> ? ? >> > I am open to suggestions. Thanks!
>>>>>> ? ? >> > Sameer.
>>>>>> ? ? >> >
>>>>>> ? ? >> >
>>>>>> ? ? >>
>>>>>> ? ? >> > --
>>>>>> ? ? >> > Pending work: http://drupal.org/project/issues/documentation/
>>>>>> ? ? >> > List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>> ? ? >> >
>>>>>> ? ? >> --
>>>>>> ? ? >> Pending work: http://drupal.org/project/issues/documentation/
>>>>>> ? ? >> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>> ? ? >
>>>>>> ? ? >
>>>>>> ? ? > --
>>>>>> ? ? > Pending work: http://drupal.org/project/issues/documentation/
>>>>>> ? ? > List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>> ? ? >
>>>>>> ? ? --
>>>>>> ? ? Pending work: http://drupal.org/project/issues/documentation/
>>>>>> ? ? List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> --
>>>>>> Pending work: http://drupal.org/project/issues/documentation/
>>>>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>>
>>>>>>
>>>>> --
>>>>> Pending work: http://drupal.org/project/issues/documentation/
>>>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Pending work: http://drupal.org/project/issues/documentation/
>>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>>
>>>>
>>> --
>>> Pending work: http://drupal.org/project/issues/documentation/
>>> List archives: http://lists.drupal.org/pipermail/documentation/
>>>
>>>
>> --
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>>
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>

From kvantomme at gmail.com  Fri Mar  6 20:44:18 2009
From: kvantomme at gmail.com (Kristof Van Tomme)
Date: Fri, 6 Mar 2009 21:44:18 +0100
Subject: [documentation] Building the Dojo
Message-ID: <f47e030903061244o57658165xf24343fd6522145@mail.gmail.com>

Hi,

on the 27th of March I'm having my first Drupal introduction class for
this semester here at the unie. We'll have approximately 15-25
students (it's a extra course, some students don't show up).

We'll have 6 people with Drupal experience mentoring them. We did a
low level check on the students so most of them know some PHP, HTML
and CSS, and we give them a basic introduction into Drupal on 27/3 and
3/4.

These students have to do a Drupal web development project to get
their credits, so I was thinking that at least part of them we could
have working on a couple of first iterations for the Drupal Dojo. Not
all of us would be working on the Dojo, but I can imagine 2-4 groups
doing consecutive SCRUM iterations (maybe on 3 consecutive weekends).

We could work from the spec at
http://groups.drupal.org/open-learning-and-collaboration-portal

The mentors probably could function as SCRUM masters, and maybe come
together with their group of students during 1 weekend.

What do you think of this idea? Does anybody have practical ideas on
how to make this a success?

Cheers,
Kristof


*****************************

I blog at http://www.pronovix.com/blog
Twitter at http://twitter.com/kvantomme

You can find my profiles on
LinkedIn at http://www.linkedin.com/in/kvantomme
XING at https://www.xing.com/profile/Kristof_VanTomme
and Facebook at http://www.facebook.com/people/Kristof-Van-Tomme/618847872











2009/2/5 Gus Austin <gus at pepperalley.com>:
> Hi,
>
> I chatted to George in the IRC about some projects/initiatives complimentary
> to what's being discussed here. The following thread should give you some
> background and an idea how things are moving forward with one of them -
> http://groups.drupal.org/node/15832
>
> The aggregation element has been broken out into it's own subproject
> (http://groups.drupal.org/node/16873) and the goal is to create something
> modular that could easily be set up on the Dojo site, on official channels
> (g.d.o./d.o.), or anywhere else it would make sense.
>
> There's already a good foundation, skilled team coming together, and it
> would great to combine forces build something that would be very valuable to
> the community.
>
> Come join the fun!
>
> On Wed, Feb 4, 2009 at 2:48 PM, George <g at 8vue.com> wrote:
>>
>> Kristof, heck yeah, i'd love any help i can get :) i just haven't
>> thought that far ahead and really shouldn't be writing emails late at
>> night! please send me your email, so i can contact you directly.
>>
>> Kristof Van Tomme wrote:
>> > Hi George,
>> >
>> > I'm not sure if you got my email, the only reference I see is about
>> > the bookmarks.
>> >
>> > What about
>> > -multi-lingual resources?
>> > -my offer to help?
>> >
>> >
>> > -There is a big chance I'll be involved in the video team at the next
>> > European Drupalcon (e.g. for sure if Maastricht wins, possibly if
>> > Paris wins).
>> > -I have access to the Szeged video material (we put it online).
>> >
>> >
>> > But if you want to go it alone good luck =D
>> >
>> > Cheers,
>> > Kristof
>> >
>> >
>> >
>> >
>> > 2009/2/4 George <g at 8vue.com>:
>> >
>> >> Yeah, Addi's hit on the important point of time consumption. That's why
>> >> I was thinking it's important to 'use' the community as much as
>> >> possible, allowing it to add new videos (trusted members though) to
>> >> allow the site to grow.
>> >>
>> >> Addi's also hit upon something I didn't think about, and that was the
>> >> forking of the comments for each video. Good point - thanks! maybe it
>> >> would be better to leave it off for the resources. or, someway to track
>> >> the comments on the original site...
>> >>
>> >> Defining a clear set of rules for QC would be difficult, I would assume
>> >> as we have different learning styles, some prefer visual, audio, or
>> >> kineasthetic means of learning, we may favour different explanations of
>> >> a question depending on these styles. So, it may be good to have
>> >> different persons 'reviewing'. That way, if users find they favour one
>> >> particular style, they can look at that particular reviewer for videos.
>> >>
>> >> After spending 5 hours producing a video which explains (badly) how to
>> >> create a recipe cck node type, a video producer could be pissed off
>> >> with
>> >> it being rejected, so maybe to allieviate this, implement a
>> >> gold/silver/bronze rating to 'shut them up' and to not put them off for
>> >> the future? they could in 3 months time be producing better vids, which
>> >> they'd be feeding directly to the site.
>> >>
>> >> I think a bookmark site is useless for research / help. With 200
>> >> gabazillion bookmarks, and seeing 4,999 'resources' tagged under cck
>> >> wouldn't turn me on.
>> >>
>> >> in summary, a one-size-fits-all site is prolly not going to be
>> >> effective, a traditional user-voted content site will be at risk of
>> >> being manipulated, so it's finding a happy medium between these two.
>> >> Also, i need to prevent putting people off from submitting resources to
>> >> the site - so constructive criticism should be given where necessary.
>> >>
>> >> On paper it could be a lot of things, so i'm going to try and start
>> >> with
>> >> the core goal, and hopefully work outwards!
>> >>
>> >> Any other ideas/suggestions?
>> >> --
>> >> Pending work: http://drupal.org/project/issues/documentation/
>> >> List archives: http://lists.drupal.org/pipermail/documentation/
>> >>
>> >>
>> > --
>> > Pending work: http://drupal.org/project/issues/documentation/
>> > List archives: http://lists.drupal.org/pipermail/documentation/
>> >
>>
>> --
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>

From drupal at rocktreesky.com  Sun Mar  8 18:39:19 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Sun, 8 Mar 2009 14:39:19 -0400
Subject: [documentation] Doc sprint post and kudos!
Message-ID: <6361283D-08DF-4C24-B708-82FCE18F3CA2@rocktreesky.com>

First, I want to say again for those that weren't in the doc sprint  
room at the end of the day: THANK YOU! You don't know how happy,  
excited and energized I was by all of the people, all of the ideas and  
work done by the doc team at this conference and sprint. You all  
totally rule. I feel great about where Drupal docs are headed and I  
can see some crazy great stuff happening this year with this crew. I  
am truly standing on the shoulders of giants.

I want to give big props to the cat herders and everyone that just  
picked up a ball and ran with it. Also a shout out to Jack  
(palantetech) for writing up an awesome post about the sprint (http://drupal.org/node/394806 
). I've promoted it to the front page of Drupal.org and we have  
comments on, so if you were involved in the sprint in some way, please  
add the work you did and/or your thoughts about experience. I have a  
lot of email and work to dig out of, as I am sure many of you do too,  
but I plan to do more blog posts soon. I'd love to see more doc blog  
posts from around the webosphere.

- Addi

From pwolanin at gmail.com  Tue Mar 10 13:16:38 2009
From: pwolanin at gmail.com (Peter Wolanin)
Date: Tue, 10 Mar 2009 09:16:38 -0400
Subject: [documentation] security forum/feed split plan.
Message-ID: <2247a8a70903100616u5d61d3e2jabb65ad12f94eb0d@mail.gmail.com>

Based on the DCDC security team BoF and discussions with G?bor and
general sign-off from Heine and other security team members yesterday,
below is a plan that I will carry forward and execute (with your help)
in the coming day or so.  The goal of this plan is to more clearly
distinguish core and contrib security issues and make the good record
of Drupal core more apparent.  If you feel that there are serious
problems with the plan, please write back as soon as possible.

All existing SAs will be divided among 3 forums:

- Drupal core security advisories
- Contributed project security advisories
- Security public service announcements

Since there are fewer core SAs and PSAs than contrib SAs, we'll make
two new forums for core and PSAs and move the existing forum nodes to
those.  It appears that the lists module that is part of the drupalorg
project will support multiple forum tids going to a single list, so
after the topics are moved someone with root access will just need to
edit settings.php to add the new tids to the settings array.

These 2 aliases will be pointed to the new core SA forum tid taxonomy page/feed:
http://drupal.org/security
http://drupal.org/security/rss.xml

We will add new aliases for the other tids like:

http://drupal.org/contrib-security
http://drupal.org/contrib-security/rss.xml
http://drupal.org/security-psa
http://drupal.org/security-psa/rss.xml

All 3 of the taxonomy pages will get the 3 blocks currently on
http://drupal.org/security

For the short term at least, the block at the top left will just
contain links to all 3 pages and feeds.  In the longer term, we might
do something more clever like add tabs to the /security page

Probably some minor handbook changes will be needed to reflect this
re-organization.

-Peter

From pwolanin at gmail.com  Tue Mar 10 17:24:56 2009
From: pwolanin at gmail.com (Peter Wolanin)
Date: Tue, 10 Mar 2009 13:24:56 -0400
Subject: [documentation] security forum/feed split plan.
In-Reply-To: <2247a8a70903100616u5d61d3e2jabb65ad12f94eb0d@mail.gmail.com>
References: <2247a8a70903100616u5d61d3e2jabb65ad12f94eb0d@mail.gmail.com>
Message-ID: <2247a8a70903101024o485248bdm8f4df7c4eeb20afc@mail.gmail.com>

Initial changes have been completed, though there may need to be some
tweaks to the block content.

-Peter


On 3/10/09, Peter Wolanin <pwolanin at gmail.com> wrote:
> Based on the DCDC security team BoF and discussions with G?bor and
>  general sign-off from Heine and other security team members yesterday,
>  below is a plan that I will carry forward and execute (with your help)
>  in the coming day or so.  The goal of this plan is to more clearly
>  distinguish core and contrib security issues and make the good record
>  of Drupal core more apparent.  If you feel that there are serious
>  problems with the plan, please write back as soon as possible.
>
>  All existing SAs will be divided among 3 forums:
>
>  - Drupal core security advisories
>  - Contributed project security advisories
>  - Security public service announcements
>
>  Since there are fewer core SAs and PSAs than contrib SAs, we'll make
>  two new forums for core and PSAs and move the existing forum nodes to
>  those.  It appears that the lists module that is part of the drupalorg
>  project will support multiple forum tids going to a single list, so
>  after the topics are moved someone with root access will just need to
>  edit settings.php to add the new tids to the settings array.
>
>  These 2 aliases will be pointed to the new core SA forum tid taxonomy page/feed:
>  http://drupal.org/security
>  http://drupal.org/security/rss.xml
>
>  We will add new aliases for the other tids like:
>
>  http://drupal.org/contrib-security
>  http://drupal.org/contrib-security/rss.xml
>  http://drupal.org/security-psa
>  http://drupal.org/security-psa/rss.xml
>
>  All 3 of the taxonomy pages will get the 3 blocks currently on
>  http://drupal.org/security
>
>  For the short term at least, the block at the top left will just
>  contain links to all 3 pages and feeds.  In the longer term, we might
>  do something more clever like add tabs to the /security page
>
>  Probably some minor handbook changes will be needed to reflect this
>  re-organization.
>
>
>  -Peter
>

From gabor at hojtsy.hu  Wed Mar 11 08:25:12 2009
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Wed, 11 Mar 2009 09:25:12 +0100
Subject: [documentation] [infrastructure] [security] security forum/feed
	split plan.
In-Reply-To: <B8A4ADDF-D0D2-4C0A-9D1B-5FB7105E6224@dwwright.net>
References: <2247a8a70903100616u5d61d3e2jabb65ad12f94eb0d@mail.gmail.com>
	<B8A4ADDF-D0D2-4C0A-9D1B-5FB7105E6224@dwwright.net>
Message-ID: <86ca3ccb0903110125k351f09dbs7b7e53064cad98be@mail.gmail.com>

On Wed, Mar 11, 2009 at 7:51 AM, Derek Wright <drupal at dwwright.net> wrote:
> We've got views on d.o. ?This seems like a great use for it. ?It can handle
> all the menu/tab stuff for us, and Views handling of feeds is really nice,
> too. ?Just make /security/core the default tab at /security, but have tabs
> for contrib and announcements and we're done. ?I could help with this if
> necessary.

It would be good to make up a Views based solution for doing these
"right sidebar filter arrows" as done on the redesigned news page (and
as discussed with Mark will be done on the jobs and events page as
well): http://drupal.markboultondesign.com/iteration11/news.html I
imagine the security page would use these kind of filter arrows as
well in the redesign, since the same concept applies.

G?bor

From drupal at rocktreesky.com  Wed Mar 11 13:34:02 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Wed, 11 Mar 2009 09:34:02 -0400
Subject: [documentation] March docs challenge
References: <20090311133046.5254A16B4E4@www1.drupal.org>
Message-ID: <D770B8D1-2C97-4440-AFFA-FD8F515C7C04@rocktreesky.com>

> add1sun has posted at http://groups.drupal.org/node/19963
>
> March docs challenge
> ---------------
> The March docs challenge (http://rocktreesky.com/docs-challenge-march-style-guide-review 
> ) is now up - better late than never! This month we are going to try  
> to make things spiffy by applying the new, updated style guide to  
> the handbook.
>
> I'll be working on it myself and hanging out in IRC from 7-8 pm EDT  
> (4 pm PDT) each Monday evening for the rest of March. I encourage  
> everyone to dig in whenever they have time, even if it is only 15-30  
> minutes every so often and, if you are an IRC kinda person, please  
> hang out in #drupal-docs to help answer questions.
>


From darthsteven at gmail.com  Thu Mar 12 21:21:55 2009
From: darthsteven at gmail.com (Steven Jones)
Date: Thu, 12 Mar 2009 21:21:55 +0000
Subject: [documentation] Drupal API documentation
Message-ID: <f27865f50903121421v3c1e39c5m911be6a0858e2ec3@mail.gmail.com>

Hi everyone,

At the documentation sprint last Saturday a number of us gathered to
talk about the documentation of Drupal's API, specifically Form API.
Although we planned and discussed FAPI specifically, there would be a
good case for applying the same style and structure of documentation
to other APIs.

I've attached a file that shows a very rough outline of what we came up with.
The documentation will be split into two components, one on a.d.o and
one in the d.o handbooks (actually two on d.o, if we include the
themer's guide.)

The forms reference on a.d.o is absolutely fine as is, so we'll leave
it alone, but the quickstart guide is going to get a trim and tidy up.

The handbook section will start with an overview of FormAPI and why
you'd want to use it. Then we'd have version specific information,
comprising a quick tutorial (in more depth than the one on a.d.o), a
section for code examples and a section explaining the 'inner
workings' of the API.

I'd like to get feedback on the proposed structure, and if there's no
major objections, I'm going to start moving the handbook pages around
on the weekend, people can then feel free to dive in and help where
they can.

Potentially we'll use this type of structure to document all the other
major APIs in Drupal, so comments are very welcome!

Regards
Steven Jones
ComputerMinds ltd - Perfect Drupal Websites

Phone : 0121 288 0434
Mobile : 07951 270 026
http://www.computerminds.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: form_api_doc_layout.png
Type: image/png
Size: 63997 bytes
Desc: not available
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090312/975bb5d6/attachment-0001.png>

From bamlhs at hotmail.com  Thu Mar 12 22:08:00 2009
From: bamlhs at hotmail.com (bamlhs at hotmail.com)
Date: Thu, 12 Mar 2009 15:08:00 -0700
Subject: [documentation] Vacation reply
In-Reply-To: <f27865f50903121421v3c1e39c5m911be6a0858e2ec3@mail.gmail.com>
Message-ID: <COL0-MC1-F13F1C340F9056F042D875CD69F0@phx.gbl>

An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090312/922f010a/attachment.htm>

From gabor at hojtsy.hu  Fri Mar 13 09:36:10 2009
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Fri, 13 Mar 2009 10:36:10 +0100
Subject: [documentation] Drupal API documentation
In-Reply-To: <f27865f50903121421v3c1e39c5m911be6a0858e2ec3@mail.gmail.com>
References: <f27865f50903121421v3c1e39c5m911be6a0858e2ec3@mail.gmail.com>
Message-ID: <86ca3ccb0903130236h450ba966t538ca8e0bb9026b7@mail.gmail.com>

On Thu, Mar 12, 2009 at 10:21 PM, Steven Jones <darthsteven at gmail.com> wrote:
> I'd like to get feedback on the proposed structure, and if there's no
> major objections, I'm going to start moving the handbook pages around
> on the weekend, people can then feel free to dive in and help where
> they can.
>
> Potentially we'll use this type of structure to document all the other
> major APIs in Drupal, so comments are very welcome!

There are quite a few of the internal APIs documented at
http://drupal.org/node/326 on various levels. I for one built out the
Localization API subsection and all its subpages:
http://drupal.org/node/322729

One useful tip I'd add from there is that IMHO it is a good idea to
include a cheat sheet up front, so that people can follow the detailed
docs along with a cheatsheet in hand. That cheatsheet includes common
mistakes and reference to tool to use to check whether you use the API
correctly :)

G?bor

From bamlhs at hotmail.com  Fri Mar 13 09:36:52 2009
From: bamlhs at hotmail.com (bamlhs at hotmail.com)
Date: Fri, 13 Mar 2009 02:36:52 -0700
Subject: [documentation] Vacation reply
In-Reply-To: <86ca3ccb0903130236h450ba966t538ca8e0bb9026b7@mail.gmail.com>
Message-ID: <BAY0-MC12-F193A8C2B7C2B2FC5129370D69C0@phx.gbl>

An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090313/8ed4f51f/attachment.htm>

From dipench at gmail.com  Fri Mar 13 09:49:30 2009
From: dipench at gmail.com (Dipen)
Date: Fri, 13 Mar 2009 15:19:30 +0530
Subject: [documentation] Drupal API documentation
In-Reply-To: <86ca3ccb0903130236h450ba966t538ca8e0bb9026b7@mail.gmail.com>
References: <f27865f50903121421v3c1e39c5m911be6a0858e2ec3@mail.gmail.com>
	<86ca3ccb0903130236h450ba966t538ca8e0bb9026b7@mail.gmail.com>
Message-ID: <1fcccc8a0903130249m5264f346rdec94d270f543bc6@mail.gmail.com>

hi gabor,
 I've seen cheatsheet made by you and was very fancy and jazzy. I've never
made one myself but would like to, do you have any special recipe apart from
the knowledge base and thorough planning? Do you use any special tools etc?

Thanks



On Fri, Mar 13, 2009 at 3:06 PM, G?bor Hojtsy <gabor at hojtsy.hu> wrote:

> On Thu, Mar 12, 2009 at 10:21 PM, Steven Jones <darthsteven at gmail.com>
> wrote:
> > I'd like to get feedback on the proposed structure, and if there's no
> > major objections, I'm going to start moving the handbook pages around
> > on the weekend, people can then feel free to dive in and help where
> > they can.
> >
> > Potentially we'll use this type of structure to document all the other
> > major APIs in Drupal, so comments are very welcome!
>
> There are quite a few of the internal APIs documented at
> http://drupal.org/node/326 on various levels. I for one built out the
> Localization API subsection and all its subpages:
> http://drupal.org/node/322729
>
> One useful tip I'd add from there is that IMHO it is a good idea to
> include a cheat sheet up front, so that people can follow the detailed
> docs along with a cheatsheet in hand. That cheatsheet includes common
> mistakes and reference to tool to use to check whether you use the API
> correctly :)
>
> G?bor
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090313/da051600/attachment.htm>

From bamlhs at hotmail.com  Fri Mar 13 09:50:04 2009
From: bamlhs at hotmail.com (bamlhs at hotmail.com)
Date: Fri, 13 Mar 2009 02:50:04 -0700
Subject: [documentation] Vacation reply
In-Reply-To: <1fcccc8a0903130249m5264f346rdec94d270f543bc6@mail.gmail.com>
Message-ID: <SNT0-MC4-F6BD8F56F204132FC47A9AD69C0@phx.gbl>

An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090313/7ef748b2/attachment.htm>

From gabor at hojtsy.hu  Fri Mar 13 10:22:36 2009
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Fri, 13 Mar 2009 11:22:36 +0100
Subject: [documentation] Drupal API documentation
In-Reply-To: <1fcccc8a0903130249m5264f346rdec94d270f543bc6@mail.gmail.com>
References: <f27865f50903121421v3c1e39c5m911be6a0858e2ec3@mail.gmail.com>
	<86ca3ccb0903130236h450ba966t538ca8e0bb9026b7@mail.gmail.com>
	<1fcccc8a0903130249m5264f346rdec94d270f543bc6@mail.gmail.com>
Message-ID: <86ca3ccb0903130322i1b9bd0fane5f1e346e0b217b2@mail.gmail.com>

Hi Dipen,

On Fri, Mar 13, 2009 at 10:49 AM, Dipen <dipench at gmail.com> wrote:
> ?I've seen cheatsheet made by you and was very fancy and jazzy. I've never
> made one myself but would like to, do you have any special recipe apart from
> the knowledge base and thorough planning? Do you use any special tools etc?

There is no special tool required. You can easily do a cheat sheet
with OpenOffice or Word, just use text boxes with page attached
positioning (ie. do not use the regular paragraph flow).

G?bor

From drupal at rocktreesky.com  Sun Mar 15 12:38:40 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Sun, 15 Mar 2009 08:38:40 -0400
Subject: [documentation] New documentation module (proof of concept)
References: <20090315123049.B780416B4E6@www1.drupal.org>
Message-ID: <956C161C-DDE1-40D0-8C37-CF7A641D918C@rocktreesky.com>

> add1sun has posted a Discussion at http://groups.drupal.org/node/20127
>
> New documentation module (proof of concept)
> ---------------
> There has been a small group of people looking at how to use  
> Advanced help in Drupal 6 (and the new help system in Drupal 7) to  
> add documentation about Drupal right into a site. Last week Adam  
> Moore (redndahead) and a small team of sprinters worked on  
> screenshot madness with the idea that we will eventually get this  
> sorted out. I have had a proof of concept module sitting around for  
> a while on my desktop and now that we really seem to be getting  
> momentum, and I inexplicably woke up at 3:30 am this morning, I  
> finally gave it a good look over, changed some stuff and committed a  
> very, very barebones module to CVS. This should let people be able  
> to play with the concept on their own sites to make it more real  
> while we figure out exactly how we want to organize it, standards we  
> need, etc. It also gives us something tangible to make patches for  
> and use for testing out other advanced things we need to do, like  
> syncing it with Drupal.org handbook pages. So, here are the  
> important bits:
>
>
> 1. We have a new component in the Documentation issue queue, called  
> Documentation module, to use for all issues about the module.
>
> 2. I will not make an official release for this, but since I know  
> many docs folks are not going to grab this directly from CVS, I have  
> made a dev snapshot tarball we can use for playing to help  
> discussion - http://drupal.org/node/402496. (For CVS users, the  
> module is currently in HEAD, contributions/modules/documentation.)

> 3. The code is for Drupal 6 and requires the Advanced help module.  
> Instructions here (for now): http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/documentati 
> ...

> 4. Yes, this is code in CVS. Changes can only be made with patches  
> and I'm the only person with commit access right now (well, except  
> Dries ;-)). Most of the work on this for now will be discussion as  
> we figure out how to set things up. When we get to actually filling  
> out docs we will look at how that will happen and who can do it.

> 5. We're not gonna go nuts filling out the docs just yet. It doesn't  
> sync with Drupal.org yet and until we get a better temperature on  
> the likelihood of that I'd hate to do tons of duplicative work.
>
> Some things we need to discuss:
>
> 1. What should be in the documentation module? We aren't going to be  
> able to put the whole handbook in there. We should start small and  
> focused and add as we go. For now, I have starter pages for cron,  
> upgrading and terminology (these aren't even complete pages - I just  
> grabbed the text from the existing top-level handbook pages).

> 2. How do we want to organize this? We can have a master docs module  
> that has sub-modules for various sections if we want. This would  
> allow us to have different top-level sections rather than everything  
> under "documentation." It wold also allow admins to turn off  
> sections they don't want for whatever reason.

> 3. What "special" standards do we need to create that are different  
> or above and beyond the current spanky, new style guide for the D.o  
> handbooks?

> 4. I'm sure there are other thoughts, concerns and topics out there  
> too. Feel free to get the discussion going - either on the mailing  
> list (where this will also be posted) or the issue queue, using the  
> new Documentation module component.


From bamlhs at hotmail.com  Sun Mar 15 12:39:17 2009
From: bamlhs at hotmail.com (bamlhs at hotmail.com)
Date: Sun, 15 Mar 2009 05:39:17 -0700
Subject: [documentation] Vacation reply
In-Reply-To: <956C161C-DDE1-40D0-8C37-CF7A641D918C@rocktreesky.com>
Message-ID: <BAY0-MC11-F14D9CFAADD27578D4A155AD69A0@phx.gbl>

An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090315/1a1a0f04/attachment.htm>

From drupal at rocktreesky.com  Sun Mar 15 13:51:48 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Sun, 15 Mar 2009 09:51:48 -0400
Subject: [documentation] New documentation module (proof of concept)
References: <20090315133059.AB27016B4E6@www1.drupal.org>
Message-ID: <AF086F55-C015-4919-85BC-0062DBFFBB3B@rocktreesky.com>

> Comment 'I'll be releasing my modules today' by robertDouglass
>
> They include:
>
> book2advhelp: a module to export Drupal book structures to the files  
> needed by advanced help. Thus you'll be able to write documentation  
> using Drupal and export it for use by advanced help.
> helpinject: a module that lets you "inject" advanced help icons into  
> Drupal pages and form elements. Any page and any form element can  
> get context sensitive help. This can either be done for just the  
> site running helpinject (for custom help on that site), or can be  
> exported to a new module that does the injecting in a distributable  
> way.
>
> Using these, Jam (horncologne) and I will be starting an effort to  
> document Drupal 6 and distribute the help+module needed to have  
> context sensitive help in Drupal 6 (as a downloadable project)  
> (we'll be recruiting help writers to assist with this effort)
> This is a step in a possible solution for the core help strategy. It  
> assumes that we'll end up with something in D7 that resembles  
> advanced help in some way. It assumes that documentation is best  
> written online in a collaborative content management system (like  
> Drupal). It assumes that the infrastructure team would be able to  
> run the export functions during the packaging process (and possible  
> check the code into CVS as well - this point will generate debate).
> The good news is, I'll be releasing these today, I expect. Will post  
> back with a link.
>
>
> View original: http://groups.drupal.org/node/20127#comment-69597
> Post a reply: http://groups.drupal.org/comment/reply/20127/69597
>
> --
> This is an automatic message from groups.drupal.org

Note, I forgot to shut off comments on the g.d.o post so I'll manually  
route things back and forth to keep the conversation straight. :-/ If  
anyone wants to help with getting the mailing list and g.d.o sync'd  
up, please talk to Moshe or Josh Koenig about how to help. ;-)

- Addi

From thomas at nutshell.nu  Sun Mar 15 15:11:56 2009
From: thomas at nutshell.nu (Thomas Svenson)
Date: Sun, 15 Mar 2009 16:11:56 +0100
Subject: [documentation] Future proof Drupal documentation structure proposal
Message-ID: <49BD1ABC.3050303@nutshell.nu>

Hi all,

I have only been using Drupal for a few months, and just started to 
contribute back to the community with a little documentation and help 
for others who are new to Drupal.

The one thing that has been hardest to tackle for me is to find relevant 
information for the tasks I need to perform on my own Drupal sites. The 
current documentation is quite unstructured and it took me quite a while 
before I learned the best methods to use to find what I needed.

While this is still fresh for me I thought it would be a good idea to 
write down my thoughts about how this could be improved and restructured 
so it would be easier for both new Drupal users and more seasoned Drupal 
experts. What I have come up with is a more role based documentation 
structure that I think will make it easier to find what a user is 
looking for and that will be much more expandable and future proof.

My goal with this was to come up with one hierarchy that can be expanded 
as new versions are released as well as addressing the needs of both 
beginners and experienced users.

Top Level Categories
=====================
This is what will shown when clicking the Documentation link.

Getting Started with Drupal
----------------------------
This will only contain documentation and guides on how to download and 
install the currently supported versions of Drupal Core.

Site Administration
--------------------
Here you will find documentation for administration. This includes 
topics such as adding and configuration of modules, updating or 
upgrading, and user management.

Site Building
--------------
This category will contain everything about how build a Drupal site. 
This includes themes, creating content types, site structure, taxonomy 
and so on.

Content Editing
----------------
This sections is for those who will add content to the site. It will 
contain documentation such as how to use WYSIWYG editors and filling in 
forms.

Development
------------
Here all documentation on how to develop for Drupal is collected, both 
for Core and contributed modules.

Document Structure
===================
Looking at the documentation today, a lot cover several Drupal versions 
mixed in the same page. For a beginner this can be a quite big hurdle to 
filter, but it also makes it difficult to maintain as well as update 
when new versions are released.

Also, it does not make it easy for beginners or advanced users to be 
able to quickly find documentation targeted to their level and needs.

I believe some big benefits with my suggestion is that we will be able 
to have one document structure that will cover every version and any 
level of experience, as well as being much easier to maintain.

Version Tabs
-------------
I like the way I can filter modules based on the Drupal version for a 
site and I think this can be reused for documentation as well.

I would like that each page has two sections. The top section is a short 
general information that is for every version of Drupal. The bottom 
section is tabs with one tab for each major version + an optional 
Current tab.

The Current tab is used if the information for 5.x and 6.x is exactly 
the same. If there are any differences between 5.x and 6.x then those 
will then be in separate tabs and there will be no Current tab.

Each tab will have complete information so the user doesn't have to 
first read the 5.x and then the 6.x to see the difference.

When a new major version is released and there are difference, it will 
be very simple to add that information:

- Click on "Add version specific tab"
- If there is a Current tab, set what version(s) it is for
- Set the version for which the new tab is for
- The content editor will be pre-loaded with the content from the tab 
that was forked
- Edit the content by removing irrelevant information and add the new

Beginner / Advanced
--------------------
As I was updating Drupal for the first time I tried to search for good 
documentation, but I only found bits and pieces here and there. Based on 
that I created "HowTo: Updating Drupal 6.x to newer minor version", 
http://drupal.org/node/390448. For a beginner that HowTo is useful as it 
contains all needed information on one page, as well as explanations to 
why and how. For an advanced user though it contains too much information.

My suggestion here is simply to have a sub tab for each version, one 
Beginner and one Advanced. When selecting Beginner you would get the 
above HowTo, but when selecting Advanced you will get a much shorter 
version where all the extra content aimed for beginners is taken out.

Preferable both are based on the same content structure as you could 
then easily switch between them when needed. Then it will also be easy 
to first create the Advanced and then simply use that as base for the 
Beginner and fill in the blanks.


Documentation Defaults
=======================
The Documentation section will remember the Drupal version and 
Beginner/Advanced tabs so that when I click on a link to another page 
they will be used as default view values.


Content Types & Filtering
==========================
There are many ways of creating documentation. It can be everything from 
reference texts, HowTo's, tutorials, videos and so on. I believe it will 
be quite easy to fit them all in the the structure I have outlined above.

When creating a new piece of documentation there needs to be more 
taxonomy options to set. Some are set automatically when the page is 
added (as described above) and some are set manually.

I propose something like:
- Media Type
  - Document
  - Video
- Type
  - Reference
  - HowTo
  - Tutorial
- Drupal version
- Beginner/Advanced

It would then be very nice if it was possible to filter in search so I 
for example can click a checkbox that I only want to get search results 
for HowTo documents for the key words or phrases.


Related Content
================
For each page it should be easy to add links to related content. If 
someone, for example, creates a video that is based on my update HowTo, 
then a link to it, and wise verse, from the HowTo will be available.


Oki, I hope you like my proposal and that some of it can be used to 
improve the Drupal documentation.

/thomas

From bamlhs at hotmail.com  Sun Mar 15 15:19:00 2009
From: bamlhs at hotmail.com (bamlhs at hotmail.com)
Date: Sun, 15 Mar 2009 08:19:00 -0700
Subject: [documentation] Vacation reply
In-Reply-To: <49BD1ABC.3050303@nutshell.nu>
Message-ID: <BAY0-MC11-F10123D63E17614D8E539E7D69A0@phx.gbl>

An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090315/9ffe8ead/attachment.htm>

From gabor at hojtsy.hu  Mon Mar 16 16:23:09 2009
From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=)
Date: Mon, 16 Mar 2009 17:23:09 +0100
Subject: [documentation] [security] [infrastructure] security forum/feed
	split plan.
In-Reply-To: <4C1AFB1C-BB75-443D-91C4-32008FB0CA20@dwwright.net>
References: <2247a8a70903100616u5d61d3e2jabb65ad12f94eb0d@mail.gmail.com>
	<B8A4ADDF-D0D2-4C0A-9D1B-5FB7105E6224@dwwright.net>
	<4C1AFB1C-BB75-443D-91C4-32008FB0CA20@dwwright.net>
Message-ID: <86ca3ccb0903160923r360c3838w918f096f93a74502@mail.gmail.com>

On Mon, Mar 16, 2009 at 5:18 PM, Derek Wright <drupal at dwwright.net> wrote:
> Now deployed on d.o:
>
> http://drupal.org/security
> http://drupal.org/security/contrib
> http://drupal.org/security/psa
>
> Interested readers can see http://drupal.org/node/398484 for the gory
> details.

Ok, looks like we need a front page announcement and/or PSA about this.

G?bor

From plaxo at mx.plaxo.com  Wed Mar 18 08:00:49 2009
From: plaxo at mx.plaxo.com (James Chibuye)
Date: Wed, 18 Mar 2009 01:00:49 -0700
Subject: [documentation] James Chibuye added you as a business connection on
	Plaxo
Message-ID: <6e64c39219b6f605ac5cbd0f4405aa58@xpertmailer.com>



James Chibuye wants to add you as a business connection on
Plaxo.

To accept this connection request, go to:
http://www.plaxo.com/invite?i=64155363&k=491337297&l=en&src=email&et=1&est=business&etv=nnic1b2&el=en

Thanks!
The Plaxo team

More than 20 million people use Plaxo to keep in touch with the
people they care about. 

Don't want to receive emails from Plaxo any more? Go to:
http://www.plaxo.com/stop?src=email&et=1&est=business&etv=nnic1b2&el=en&email=documentation%40drupal.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090318/f3aade2b/attachment.htm>

From bamlhs at hotmail.com  Wed Mar 18 08:01:25 2009
From: bamlhs at hotmail.com (bamlhs at hotmail.com)
Date: Wed, 18 Mar 2009 01:01:25 -0700
Subject: [documentation] Vacation reply
In-Reply-To: <6e64c39219b6f605ac5cbd0f4405aa58@xpertmailer.com>
Message-ID: <COL0-MC1-F302000A1CDD4AA0CF98013D6990@phx.gbl>

An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090318/68833eff/attachment-0001.htm>

From events at fancorner.womensprosoccer.com  Wed Mar 18 11:29:04 2009
From: events at fancorner.womensprosoccer.com (homeless worldcup-association)
Date: Wed, 18 Mar 2009 11:29:04 +0000 (GMT)
Subject: [documentation] Come join me at Kick out child Labour and Kicking
 out Malaria Now Tournaments on Women's Professional Soccer
Message-ID: <31171825.1237375744944.JavaMail.xncore@omx>

Women's Professional Soccer: 
homeless worldcup-association has invited you to the event 'Kick out child Labour and Kicking out Malaria Now Tournaments' on Women's Professional Soccer!
--------------------

We need your support event next coming months noble cause

Time: April 25, 2009 from 6pm to 7pm
Location: Lusaka, Zambia
Organized By: homeless worldcup-association:

Event Description:
Kick Malaria Out of Africa

Joy Human Development Centre (JHDC) is a Zambian Community NGO which was established in 2003 and focuses on youth, sports and health education. Currently providing young people with opportunities to further develop their skills, JHDC also provides health education about malaria. Sport is part of the method to educate these kids about the risks related to this disease. Sport is also used to encourage these youngsters to participate to competitive sport at an early age, which enables the centre to identify and develop young talents.

Related:
Region: Africa
Country: Zambia
Subject: Health Promotion, Human Capacity Building
Sport: Basketball, Football (Soccer), Volleyball
Target group: Youth
Project description
Image gallery
Issue
Diseases such as malaria, HIV/AIDS, sexually transmitted infections (STI) or tuberculosis, which have devastating effects worldwide, but particularly in Africa, where information related to prevention is lacking. Against this background, soccer is considered as a tool which helps reach and communicate with the children and youth in the various communities.
Objectives
The tournament seeks to:



Empower orphans, street kids and vulnerable youths by helping them build self-confidence through football and art;

Raise awareness among the participants in the area of health issues, with a particular focus on malaria prevention;

Promote the children?s right to play and thus help combat child labour;

Acquire and provide footballs and football kits;

Raise international awareness about development issues throughout Zambia and Africa.

Location
Lusaka, Zambia.
Target group
Vulnerable youths such as orphans or street children.
Use of sport
Soccer, basketball and volleyball are part of educational programmes intended to sensitize children to health issues.
Participating organisation(s)

Zambia Youth Academy
Joy Human Development Centre, Dellow Academy, Action for children, Zambia Dzitadizeni football club.
Contact
James Chibuye
Private Bag E94
10101 Lusaka
Zambia
Phone: +260 (0) 9778 227 42

See more details and RSVP on Women's Professional Soccer:
http://fancorner.womensprosoccer.com/events/event/show?id=2136787%3AEvent%3A37530&xgi=hWmiCqU

If your email program doesn't recognize the web address above as an active link,
please copy and paste it into your web browser
--------------------

About Women's Professional Soccer
Chat, blog and post about the players who will soon be starring in WPS. Play kicks off on March 29th, 2009.

3016 members
5158 photos
164 videos
312 discussions
62 events
645 blog posts

--------------------

To control which emails you receive on the corner, or to opt-out, go to:
http://fancorner.womensprosoccer.com/?xgo=aP/ep7Oen/RDy3Mha1z3L/strkiYkiOQhAnFgK7EsHCPV80sTxCV8SmqoEqdvkDS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090318/c0d5b151/attachment.htm>

From drupal at rocktreesky.com  Thu Mar 19 13:35:05 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 19 Mar 2009 09:35:05 -0400
Subject: [documentation] New documentation module (proof of concept)
References: <20090319125021.D301616B4E4@www1.drupal.org>
Message-ID: <688D3735-52BD-46B9-8F04-AF8F3EEDA5D5@rocktreesky.com>

> Comment 'Woot' by add1sun
>
> Yay! Glad this is getting out the door. For those following along at  
> home, here is the project for Advanced Help Injection and Export , http://drupal.org/project/helpinject 
> , (it includes both of the book2help and helpinject modules  
> described).
> Lullabot loves you
> Our O'Reilly book is out! Using Drupal
>
>
> View original: http://groups.drupal.org/node/20127#comment-70148
> Post a reply: http://groups.drupal.org/comment/reply/20127/70148
>
> --
> This is an automatic message from groups.drupal.org

From g at 8vue.com  Thu Mar 19 16:36:19 2009
From: g at 8vue.com (George)
Date: Thu, 19 Mar 2009 17:36:19 +0100
Subject: [documentation] New documentation module (proof of concept)
In-Reply-To: <688D3735-52BD-46B9-8F04-AF8F3EEDA5D5@rocktreesky.com>
References: <20090319125021.D301616B4E4@www1.drupal.org>
	<688D3735-52BD-46B9-8F04-AF8F3EEDA5D5@rocktreesky.com>
Message-ID: <49C27483.5080401@8vue.com>

i still think "lullabot loves you" is clever subliminal advertising.

Addison Berry wrote:
>> Comment 'Woot' by add1sun
>>
>> Yay! Glad this is getting out the door. For those following along at 
>> home, here is the project for Advanced Help Injection and Export , 
>> http://drupal.org/project/helpinject, (it includes both of the 
>> book2help and helpinject modules described).
>> Lullabot loves you
>> Our O'Reilly book is out! Using Drupal
>>
>>
>> View original: http://groups.drupal.org/node/20127#comment-70148
>> Post a reply: http://groups.drupal.org/comment/reply/20127/70148
>>
>> -- 
>> This is an automatic message from groups.drupal.org
> -- 
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/


From drupal at rocktreesky.com  Thu Mar 19 16:41:08 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 19 Mar 2009 12:41:08 -0400
Subject: [documentation] New documentation module (proof of concept)
In-Reply-To: <49C27483.5080401@8vue.com>
References: <20090319125021.D301616B4E4@www1.drupal.org>
	<688D3735-52BD-46B9-8F04-AF8F3EEDA5D5@rocktreesky.com>
	<49C27483.5080401@8vue.com>
Message-ID: <7AF9E701-F555-4903-8AED-69D3E1513C4E@rocktreesky.com>


On Mar 19, 2009, at 12:36 PM, George wrote:

> i still think "lullabot loves you" is clever subliminal advertising.

Whoops, haha. That was taken directly from my comment sig on g.d.o.  
Didn't mean to actually have that in the list email.

>
>
> Addison Berry wrote:
>>> Comment 'Woot' by add1sun
>>>
>>> Yay! Glad this is getting out the door. For those following along  
>>> at home, here is the project for Advanced Help Injection and  
>>> Export , http://drupal.org/project/helpinject, (it includes both  
>>> of the book2help and helpinject modules described).
>>> Lullabot loves you
>>> Our O'Reilly book is out! Using Drupal
>>>
>>>
>>> View original: http://groups.drupal.org/node/20127#comment-70148
>>> Post a reply: http://groups.drupal.org/comment/reply/20127/70148
>>>
>>> -- 
>>> This is an automatic message from groups.drupal.org
>> -- 
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/


From drupal at rocktreesky.com  Wed Mar 25 17:58:52 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Wed, 25 Mar 2009 13:58:52 -0400
Subject: [documentation] Updates on doc stuff/sprints
Message-ID: <B94C4D7C-9CAA-41B4-88F7-F36329A42198@rocktreesky.com>

I just wanted to send a quick note out to folks on the team. This past  
weekend there was a high-level doc sprint in Toronto and I've started  
posting about it at http://rocktreesky.com/different-kind-doc-sprint.  
There will be at least one more blog post and then a D.o front page  
post with the big takeaways and next steps (next week I hope).

I also wanted to mention that I'll be doing a doc sprint at Drupalcamp  
Galway on April 5 (http://groups.drupal.org/node/18452). If you are  
local, please come on out. I would love it if we could also do an  
online sprint at the same time (10am - 5pm GMT / 6am - 1pm EDT). It is  
near impossible to pay attention to a live and online sprint at the  
same time, so if we could get a few folks to hang out in IRC at that  
time to help people out, that would be awesome.

Doc on!
- Addi



From drupal at rocktreesky.com  Wed Mar 25 18:19:28 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Wed, 25 Mar 2009 14:19:28 -0400
Subject: [documentation] Drupal docs logos
Message-ID: <64075DC9-061C-47D8-B955-4FEC609E8C69@rocktreesky.com>

So, at the Drupalcon sprint one thing that came up was having a logo  
of sorts for docs-related posts, slides, etc. I popped my head into  
the Design 4 Drupal sprint 9as well as posting to their group on  
g.d.o) to ask if anyone would be interested in tossing some logos our  
way. So far, we've gotten two responses:

http://drupal.org/node/398412
http://drupal.org/node/408164

I don't think we need to limit ourselves to one logo and it isn't  
anything official so we can use them all.  Please feel free to give  
feedback and thanks to the designers. There is a page in the handbook  
at http://drupal.org/node/398394 to put them up on. I think once the  
designers are happy with them, we can add them to that page whenever  
so, if it looks OK to us and the designer is cool with posting up a  
"final" version, please feel free to add them (you'll need to have doc  
admin rights to add the images to the page).

Doc on!
- Addi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090325/6f8b10a6/attachment-0001.htm>

From drupal at rocktreesky.com  Sun Mar 29 17:59:37 2009
From: drupal at rocktreesky.com (Addison Berry)
Date: Sun, 29 Mar 2009 13:59:37 -0400
Subject: [documentation] Fwd: Documentation Team: 'Take a quick
	documentation survey' at groups.drupal.org
References: <20090329173016.D098916B548@www1.drupal.org>
Message-ID: <F4153C00-04CD-41CB-BD44-7924537EA2C5@rocktreesky.com>

> add1sun has posted a Discussion at http://groups.drupal.org/node/20689
>
> Take a quick documentation survey
> ---------------
> As part of the overall Drupal documentation efforts and the Knight  
> Foundation grant that was awarded this year, I will be conducting a  
> number of short surveys about documentation over the coming year.  
> The first survey, about participation is now up (http://drupaldocs.limequery.com/index.php?sid=75848 
> ). It is only 5 questions long and should only take a few minutes to  
> complete. The survey will close on Monday, April 13. The results  
> will be posted back to the Documentation group once the survey  
> closes. Thanks for helping us wrangle Drupal docs and make them  
> better for everyone.


From shai at content2zero.com  Tue Mar 31 01:57:09 2009
From: shai at content2zero.com (Shai Gluskin)
Date: Mon, 30 Mar 2009 21:57:09 -0400
Subject: [documentation] Some Background/Strategy Help Needed re: "Drupal
	Cookbook"
Message-ID: <9f68efb70903301857s3994b0bm1a93357a0b332976@mail.gmail.com>

Hi gang,

I did some work on the "title" page of the Drupal Cookbook today...

http://drupal.org/handbook/customization/tutorials/beginners-cookbook

I just jumped in, but now I'm seeing some questions I'd like to ask the
group.

The book is written in a very strong "I" voice. Who is it? I couldn't quite
tell from the revisions. I'd respectfully like to tell that person that I'd
like to put some editing work in.

Also, it seems to me like the "I" voice should be removed. That doesn't fit
the style guide and it seems kind of weird, especially since those pages
don't have authors anyway.

Another thing that is weird... the Cookbook is nested under "Beyond the
Basics" but it is also specifically referred to as "For beginners."

If there were plans to retire or replace the "Cookbook" -- I don't want to
waste time. But otherwise, I'd be happy to put some more work into it.

I'd be interested to feedback on the work that I did today on the first
page.
http://drupal.org/handbook/customization/tutorials/beginners-cookbook

I left pretty good notes in the log, and of course you could dif it. I
changed the order of things, mostly took stuff out. The place where I added
the most was in the terms definition section. I think giving some meet there
is helpful, especially for beginners, in lays an important foundation.

Thanks,

shai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090330/77f7afce/attachment.htm>

From nan_wich at bellsouth.net  Tue Mar 31 04:13:58 2009
From: nan_wich at bellsouth.net (Nancy Wichmann)
Date: Tue, 31 Mar 2009 00:13:58 -0400
Subject: [documentation] Some Background/Strategy Help Needed re:
	"DrupalCookbook"
In-Reply-To: <9f68efb70903301857s3994b0bm1a93357a0b332976@mail.gmail.com>
Message-ID: <NCEKJGCAHKMOLJLHNKLJAECMENAA.nan_wich@bellsouth.net>

I am ?I.?  I wrote in that tone to give the intended audience (beginners, as
I was at the time) more of a feeling that they can do it too.  As for the
?style guide.? Be aware that Drupal?s style guide is in contradiction with
most business style guides that I have experience with.

Originally, I argued with and convinced Steven Peck to put the Cookbook as a
top level book where beginners could actually find it. I got many
unsolicited thank you notes as a result. At some point people started
mucking with the organization and the Cookbook has been moved several times
resulting in the people who needed it not being able to find it.

Then handbooks are public property so I cannot stop you from editing it,
even if I had the mind to try. I would ask you, please, to remember that it
is for beginners, not those who already know Drupal well. Frankly, I think
anyone with more than about 9 months of Drupal experience should stay out of
it.

Some feedback:  I see several typos and grammatical errors.  The tone I read
in the first screen of the book is pretty close to exactly what I talked
about above ? pedantic and unencouraging. I wrote this book when I was into
Drupal less than 3 months; having succeeded in developing two sites at that
point, I wanted other newbies to see that they too can do it. Don?t
overwhelm them with strict definitions and technical details.

I see what you are trying to do and applaud you for the effort. Now step
back and remember what it felt like to put that first site up. Forget PHP
and Drupal internals ? they don?t mean anything to the audience for this
book. They look at most of the stuff on DO and go, ?Huh??  If you don?t
believe that, I?ll try to dig up some of the many emails I got saying that.
Keep it simple, build a little bit at a time. Allow yourself to be a bit
loose with definitions so they are better understood.

Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.

-----Original Message-----
From: documentation-bounces at drupal.org
[mailto:documentation-bounces at drupal.org]On Behalf Of Shai Gluskin
Sent: Monday, March 30, 2009 9:57 PM
To: A list for documentation writers
Subject: [documentation] Some Background/Strategy Help Needed re:
"DrupalCookbook"

Hi gang,

I did some work on the "title" page of the Drupal Cookbook today...

http://drupal.org/handbook/customization/tutorials/beginners-cookbook

I just jumped in, but now I'm seeing some questions I'd like to ask the
group.

The book is written in a very strong "I" voice. Who is it? I couldn't quite
tell from the revisions. I'd respectfully like to tell that person that I'd
like to put some editing work in.

Also, it seems to me like the "I" voice should be removed. That doesn't fit
the style guide and it seems kind of weird, especially since those pages
don't have authors anyway.

Another thing that is weird... the Cookbook is nested under "Beyond the
Basics" but it is also specifically referred to as "For beginners."

If there were plans to retire or replace the "Cookbook" -- I don't want to
waste time. But otherwise, I'd be happy to put some more work into it.

I'd be interested to feedback on the work that I did today on the first
page.
http://drupal.org/handbook/customization/tutorials/beginners-cookbook

I left pretty good notes in the log, and of course you could dif it. I
changed the order of things, mostly took stuff out. The place where I added
the most was in the terms definition section. I think giving some meet there
is helpful, especially for beginners, in lays an important foundation.

Thanks,

shai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090331/bd1699e8/attachment.htm>
-------------- next part --------------

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.11.31/2029 - Release Date: 3/29/2009 4:56 PM

From shai at content2zero.com  Tue Mar 31 17:38:11 2009
From: shai at content2zero.com (Shai Gluskin)
Date: Tue, 31 Mar 2009 13:38:11 -0400
Subject: [documentation] Some Background/Strategy Help Needed re:
	"DrupalCookbook"
In-Reply-To: <NCEKJGCAHKMOLJLHNKLJAECMENAA.nan_wich@bellsouth.net>
References: <9f68efb70903301857s3994b0bm1a93357a0b332976@mail.gmail.com>
	<NCEKJGCAHKMOLJLHNKLJAECMENAA.nan_wich@bellsouth.net>
Message-ID: <9f68efb70903311038q5d30f215q73db0727a5504c38@mail.gmail.com>

Nancy and documenters,

Nancy, nice to meet you! And great work on the Cook Book.

I really think we are on the same page. I put back some of the encouragement
language.

I think maybe the answer to some of the "I" language stuff and maybe the
volume of encouraging language is that the PDF should be different from the
web version. I have no intention of changing the PDF version. I think on the
web the "I" is just simply confusing, especially when an author isn't even
referenced anywhere but in the revisions tab.

As for the web version, I just think the pages should be shorter because
people don't read long pages on the web. Actually, I've really only looked
at the first page, so maybe the other pages are short. But the first page is
very long.

I have no interest in making it more technical at all. I took out the
reference to Windows precisely because it was a technical issue and it was
off-topic as well! You likely didn't even put that there.

"Forget PHP and Drupal internals ? they don?t mean anything to the audience
for this book."


I didn't write anything about PHP or Drupal internals. I see a reference to
PHP in the section about what to do on Drupal.org... which is way too long.
Likely you didn't put that there, and neither did I. What I did was simply
give them the path to find their PHP version and MySQL version numbers so
they aren't completely frustrated should they follow that suggestion. I
would be fine with that whole bullet coming out.

Nancy, I really think we are on the same page and that someone came in
between your edits and mine who made things more technical and/or long and
confusing. You'd really have to run the diff between two days ago version
and now to see precisely what I did.

The only parts I lengthened were the node definition and the block
definitions. And I don't think I added technical language. In the menu
definition I added that these menus are available to place in the display
via block admin. Pointing that out helps people past a huge frustration that
many face. I think what people want to know is... "how do I get control of
something to put it somewhere." That was the focus of my attention. It was a
huge aha for me when I realized that some blocks are built by modules and
other blocks you can make yourself, but both are controlled via the block
admin menu. Those are really confusing stumbling blocks that I think can be
overcome as part of a basic description, and that is why I added them.

But as I said, I really think we are much more on the same page than you
might think.

best,

Shai

2009/3/31 Nancy Wichmann <nan_wich at bellsouth.net>
>
> I am ?I.?  I wrote in that tone to give the intended audience (beginners,
as I was at the time) more of a feeling that they can do it too.  As for the
?style guide.? Be aware that Drupal?s style guide is in contradiction with
most business style guides that I have experience with.
>
>
>
> Originally, I argued with and convinced Steven Peck to put the Cookbook as
a top level book where beginners could actually find it. I got many
unsolicited thank you notes as a result. At some point people started
mucking with the organization and the Cookbook has been moved several times
resulting in the people who needed it not being able to find it.
>
>
>
> Then handbooks are public property so I cannot stop you from editing it,
even if I had the mind to try. I would ask you, please, to remember that it
is for beginners, not those who already know Drupal well. Frankly, I think
anyone with more than about 9 months of Drupal experience should stay out of
it.
>
>
>
> Some feedback:  I see several typos and grammatical errors.  The tone I
read in the first screen of the book is pretty close to exactly what I
talked about above ? pedantic and unencouraging. I wrote this book when I
was into Drupal less than 3 months; having succeeded in developing two sites
at that point, I wanted other newbies to see that they too can do it. Don?t
overwhelm them with strict definitions and technical details.
>
>
>
> I see what you are trying to do and applaud you for the effort. Now step
back and remember what it felt like to put that first site up. Forget PHP
and Drupal internals ? they don?t mean anything to the audience for this
book. They look at most of the stuff on DO and go, ?Huh??  If you don?t
believe that, I?ll try to dig up some of the many emails I got saying that.
Keep it simple, build a little bit at a time. Allow yourself to be a bit
loose with definitions so they are better understood.
>
>
>
> Nancy E. Wichmann, PMP
>
> Injustice anywhere is a threat to justice everywhere. - Martin L. King,
Jr.
>
>
>
> -----Original Message-----
> From: documentation-bounces at drupal.org [mailto:
documentation-bounces at drupal.org]On Behalf Of Shai Gluskin
> Sent: Monday, March 30, 2009 9:57 PM
> To: A list for documentation writers
> Subject: [documentation] Some Background/Strategy Help Needed re:
"DrupalCookbook"
>
>
>
> Hi gang,
>
> I did some work on the "title" page of the Drupal Cookbook today...
>
> http://drupal.org/handbook/customization/tutorials/beginners-cookbook
>
> I just jumped in, but now I'm seeing some questions I'd like to ask the
group.
>
> The book is written in a very strong "I" voice. Who is it? I couldn't
quite tell from the revisions. I'd respectfully like to tell that person
that I'd like to put some editing work in.
>
> Also, it seems to me like the "I" voice should be removed. That doesn't
fit the style guide and it seems kind of weird, especially since those pages
don't have authors anyway.
>
> Another thing that is weird... the Cookbook is nested under "Beyond the
Basics" but it is also specifically referred to as "For beginners."
>
> If there were plans to retire or replace the "Cookbook" -- I don't want to
waste time. But otherwise, I'd be happy to put some more work into it.
>
> I'd be interested to feedback on the work that I did today on the first
page.
> http://drupal.org/handbook/customization/tutorials/beginners-cookbook
>
> I left pretty good notes in the log, and of course you could dif it. I
changed the order of things, mostly took stuff out. The place where I added
the most was in the terms definition section. I think giving some meet there
is helpful, especially for beginners, in lays an important foundation.
>
> Thanks,
>
> shai
>
> No virus found in this outgoing message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.176 / Virus Database: 270.11.31/2029 - Release Date:
3/29/2009 4:56 PM
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090331/6fc4533c/attachment-0001.htm>

From nan_wich at bellsouth.net  Tue Mar 31 18:25:19 2009
From: nan_wich at bellsouth.net (Nancy Wichmann)
Date: Tue, 31 Mar 2009 14:25:19 -0400
Subject: [documentation] Some Background/Strategy Help Needed
	re:"DrupalCookbook"
In-Reply-To: <9f68efb70903311038q5d30f215q73db0727a5504c38@mail.gmail.com>
Message-ID: <NCEKJGCAHKMOLJLHNKLJKEDCENAA.nan_wich@bellsouth.net>

Shai Gluskin wrote:

> The only parts I lengthened were the node definition and the block
definitions

Shai, I apologize that I may have stated my case more strongly than needed;
I won?t go into the personal problems that have been weighing heavily on my
mind recently. I certainly welcome your work on updating the Cookbook, which
I haven?t done much of lately. It definitely needs more 6.x updates.

One of the big things I reacted to is that you made the definition of ?node?
more precise and I consciously had left it less so because the people who
read this book are just starting out and just need a very basic idea of what
a node is ? basically a piece of content (as in ?content management
 system?). The more precise definition probably belongs in the Glossary
section later in the book. Early in the book, all that is needed is a
?flavor? so they don?t get overwhelmed.

Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/documentation/attachments/20090331/2200b007/attachment.htm>
-------------- next part --------------

No virus found in this outgoing message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.11.33/2031 - Release Date: 3/30/2009 5:56 PM