From drupal at rocktreesky.com  Fri Nov  7 03:25:17 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 6 Nov 2008 22:25:17 -0500
Subject: [documentation] Open editing/limiting creation?
Message-ID: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>

So before our meeting (http://groups.drupal.org/node/163430 I wanted  
to toss out my impressions and thoughts about the open editing trial  
we are running. First, I want to say that I think it is going pretty  
well. There was an initial "rush" after we announced and a number of  
folks were just testing things out. That seems to have died down and  
typically the edits I am seeing are good, helpful edits. I've not seen  
anything spammy or purposely "vandalized" myself. Definitely more  
edits overall and some of them need a little cleanup or guidance, but  
that is no more than we get from new team members honestly. So,  
overall I'd say that we should keep going with the open editing. We've  
gotten some good help and  fewer test/weirdness/spam with it (so far)  
than we do with new page creation. Which leads me to....

One thing that has kinda bugged me for a while, and has also been  
pointed out by other folks, is that while allowing anyone to create  
new pages definitely adds to the knowledge, we get lots of test pages  
and pages in the "wrong" place. Most people who test often make a  
silly page in the Getting Started guide, which is the worst place for  
cruft. Now, we are definitely moving forward on reorganizing the docs  
(check out the redesign thread, http://groups.drupal.org/node/15965).  
Once we figure out what we are doing and the best way to implement,  
I'm inclined to keep a bit of a tighter rein on things. Now, I have  
high hopes that the "speed bump" (http://drupal.org/node/307650) will  
eventually get worked out and that will help to a degree and I think  
completely cutting of page creation rights will end up losing some  
valuable docs. Pure moderation also seems a bit too much for us right  
now and people could end up with new content inaccessible for long  
periods.

So, for now, I'm thinking about having a "holding" book. Basically we  
could let people create new pages, but they would not get to choose  
the location and it would go into a new book for this purpose. (We   
would completely restrict the ability to choose a parent for folks  
that edit as well, if they aren't on the docs team, so that people  
don't create, then move.) I guess I'm thinking of a published  
moderation queue. Then doc team and site maintainers could check the  
book regularly, quickly deleting test and spam. We can assess good  
book pages and place them appropriately. While they are "holding" they  
will still be accessible to search and to authors who wish to improve  
the page. Now I haven't thought it all through but I just wanted to  
posit the idea and see what folks think - good, bad, different ideas.


- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com







From shai at content2zero.com  Fri Nov  7 03:44:18 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Thu, 6 Nov 2008 22:44:18 -0500
Subject: [documentation] Open editing/limiting creation?
In-Reply-To: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
References: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
Message-ID: <9f68efb70811061944k3d3d529eyeb72ccff17558c56@mail.gmail.com>

Addi and documentors,

+1

I really like the idea of creating a "New pages" book and restricting
"filing" to site maintainers and docs team members.

In addition to those nodes being instantly published, searchable and easily
accessible to their authors  before they are "filed" --- is the new site
planning on any tagging goodness?  Tags could also have the affect of making
this data more easily findable.

Shai

On Thu, Nov 6, 2008 at 10:25 PM, Addison Berry <drupal at rocktreesky.com>wrote:

> So before our meeting (http://groups.drupal.org/node/163430 I wanted
> to toss out my impressions and thoughts about the open editing trial
> we are running. First, I want to say that I think it is going pretty
> well. There was an initial "rush" after we announced and a number of
> folks were just testing things out. That seems to have died down and
> typically the edits I am seeing are good, helpful edits. I've not seen
> anything spammy or purposely "vandalized" myself. Definitely more
> edits overall and some of them need a little cleanup or guidance, but
> that is no more than we get from new team members honestly. So,
> overall I'd say that we should keep going with the open editing. We've
> gotten some good help and  fewer test/weirdness/spam with it (so far)
> than we do with new page creation. Which leads me to....
>
> One thing that has kinda bugged me for a while, and has also been
> pointed out by other folks, is that while allowing anyone to create
> new pages definitely adds to the knowledge, we get lots of test pages
> and pages in the "wrong" place. Most people who test often make a
> silly page in the Getting Started guide, which is the worst place for
> cruft. Now, we are definitely moving forward on reorganizing the docs
> (check out the redesign thread, http://groups.drupal.org/node/15965).
> Once we figure out what we are doing and the best way to implement,
> I'm inclined to keep a bit of a tighter rein on things. Now, I have
> high hopes that the "speed bump" (http://drupal.org/node/307650) will
> eventually get worked out and that will help to a degree and I think
> completely cutting of page creation rights will end up losing some
> valuable docs. Pure moderation also seems a bit too much for us right
> now and people could end up with new content inaccessible for long
> periods.
>
> So, for now, I'm thinking about having a "holding" book. Basically we
> could let people create new pages, but they would not get to choose
> the location and it would go into a new book for this purpose. (We
> would completely restrict the ability to choose a parent for folks
> that edit as well, if they aren't on the docs team, so that people
> don't create, then move.) I guess I'm thinking of a published
> moderation queue. Then doc team and site maintainers could check the
> book regularly, quickly deleting test and spam. We can assess good
> book pages and place them appropriately. While they are "holding" they
> will still be accessible to search and to authors who wish to improve
> the page. Now I haven't thought it all through but I just wanted to
> posit the idea and see what folks think - good, bad, different ideas.
>
>
> - Addi (add1sun)
> --------------------------------------
> Join us at Do It With Drupal!
> A large scale, curated education event
> December 10-12, New Orleans
> http://www.doitwithdrupal.com
>
>
>
>
>
>
> --
> 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/20081106/13715c78/attachment-0001.htm 

From drupal-docs at webchick.net  Fri Nov  7 05:30:36 2008
From: drupal-docs at webchick.net (Angela Byron)
Date: Fri, 07 Nov 2008 00:30:36 -0500
Subject: [documentation] Open editing/limiting creation?
In-Reply-To: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
References: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
Message-ID: <4913D27C.8040107@webchick.net>

On 11/6/08 10:25 PM, Addison Berry wrote:
> So, for now, I'm thinking about having a "holding" book. Basically we
> could let people create new pages, but they would not get to choose
> the location and it would go into a new book for this purpose. (We
> would completely restrict the ability to choose a parent for folks
> that edit as well, if they aren't on the docs team, so that people
> don't create, then move.) I guess I'm thinking of a published
> moderation queue. Then doc team and site maintainers could check the
> book regularly, quickly deleting test and spam. We can assess good
> book pages and place them appropriately. While they are "holding" they
> will still be accessible to search and to authors who wish to improve
> the page. Now I haven't thought it all through but I just wanted to
> posit the idea and see what folks think - good, bad, different ideas.

I'll preface this by saying that I'm normally Ms. No Barriers to 
Contribution. This is a very good compromise suggestion.

However. We should also think about "what if?" for create book page 
permissions globally locked down to only docs team members.

This would offer several benefits:

1. No more spam/test pages appearing in the getting started guide, which 
is most peoples' first impressions of Drupal's documentation. Not cool. 
Of course, your proposal would deal with this too, but it requires code.

2. Docs team members have a good sense of what books are available and 
where things go, because they have their heads in this all the time. New 
users typically don't, so they'll stick stuff in a totally different 
section or duplicates pages that already exist. Requiring non-docs team 
members to add an issue for pages they'd like to add, with the text of 
the page in there, would allow docs team members to review new additions 
and head these situations off at the pass (oh, actually this page 
already exists at X. Why not edit that so that it includes the nice 
clarifications you have here?). In this way it would sort of be like the 
patch contributor / module maintainer roles we have with development 
projects.

3. With editing open to anyone, there is no longer a big incentive for 
joining the docs team, I don't think. While the docs team at the moment 
is a powerhouse of awesomeness, over time people get busy with things, 
and it's important to constantly have an influx of new blood. So making 
a "Ok, we trust you enough based on your edit contributions to give you 
create page rights now" thing might be a nice way to reward those who 
are doing a great job.

Mind you, I've obviously had my head in a totally different space the 
past few months, so I could be wildly off base.

-- 
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com

From drupal at rocktreesky.com  Fri Nov  7 14:36:58 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Fri, 7 Nov 2008 09:36:58 -0500
Subject: [documentation] Open editing/limiting creation?
In-Reply-To: <4913D27C.8040107@webchick.net>
References: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
	<4913D27C.8040107@webchick.net>
Message-ID: <085B72BC-6639-4B9F-AD24-C353E1DE1794@rocktreesky.com>

On Nov 7, 2008, at 12:30 AM, Angela Byron wrote:
> However. We should also think about "what if?" for create book page
> permissions globally locked down to only docs team members.

Overall I'm inclined to not cut it off entirely, but I'm definitely  
open to talking about that as an option. I'd really like other team  
members to weigh in on this. :-) My responses inline.

> This would offer several benefits:
>
> 1. No more spam/test pages appearing in the getting started guide,  
> which
> is most peoples' first impressions of Drupal's documentation. Not  
> cool.
> Of course, your proposal would deal with this too, but it requires  
> code.
Some code, not that much I'd say. Check if the person is on the team  
and, if not, form_alter the parent selector.

> 2. .... Requiring non-docs team
> members to add an issue for pages they'd like to add, with the text of
> the page in there, would allow docs team members to review new  
> additions
> and head these situations off at the pass (oh, actually this page
> already exists at X. Why not edit that so that it includes the nice
> clarifications you have here?). In this way it would sort of be like  
> the
> patch contributor / module maintainer roles we have with development
> projects.
I feel like requiring people to make an issue means people simply  
won't do it at all and they'll just post on their personal blog,  
dispersing the info even further. According to handbook stats more  
pages are created by non-team members: "Of the 23 added, 16 were  
created by people not on the documentation team" I'd rather let people  
make the pages and then we do that same monitoring and feedback  
without making them do the hoop dance. It would be similar to patch  
review, but docs is not code and trying to make docs follow code  
processes and conventions is one of the "problems" we are currently  
trying to get away from honestly. ;-)

> 3. With editing open to anyone, there is no longer a big incentive for
> joining the docs team, I don't think.
Well you still need to be on the team to use the doc format, which  
allows images.

> While the docs team at the moment
> is a powerhouse of awesomeness, over time people get busy with things,
> and it's important to constantly have an influx of new blood. So  
> making
> a "Ok, we trust you enough based on your edit contributions to give  
> you
> create page rights now" thing might be a nice way to reward those who
> are doing a great job.
Fewer people create new pages than most other activity in docs. I do  
plan to make the doc team more "special" as we move forward but I  
guess I personally don't see that as much of a reward. Perhaps I'm  
wrong on that one though and so it is something to consider.


- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com

From drupal at rocktreesky.com  Fri Nov  7 14:55:05 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Fri, 7 Nov 2008 09:55:05 -0500
Subject: [documentation] Reminder: IRC meeting today at 17:00 GMT (noon EST)
Message-ID: <D8D7D411-168B-4139-97C7-C967C8099656@rocktreesky.com>

Just a quick reminder that we are meeting up today, mostly to discuss  
the open editing but also to talk about a few other things. Latest  
agenda is up on the doc group (with links to some relevant stuff): http://groups.drupal.org/node/16343

We'll meet in #drupal-docs on FreeNode for one hour starting at 17:00  
GMT (noon EST, 9 am PST). [That is, approximately 2 hours from the  
time this email was sent.]


- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com







From drupal-docs at webchick.net  Fri Nov  7 16:01:24 2008
From: drupal-docs at webchick.net (Angela Byron)
Date: Fri, 07 Nov 2008 11:01:24 -0500
Subject: [documentation] Open editing/limiting creation?
In-Reply-To: <085B72BC-6639-4B9F-AD24-C353E1DE1794@rocktreesky.com>
References: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>	<4913D27C.8040107@webchick.net>
	<085B72BC-6639-4B9F-AD24-C353E1DE1794@rocktreesky.com>
Message-ID: <49146654.1070500@webchick.net>


Hmmm! Your ideas are intriguing to me, and I wish to subscribe to your 
newsletter. ;)

Yep, you did a good job shooting down all of the arguments I could think 
of for locking it down, so +1 for this direction. :)

On 11/7/08 9:36 AM, Addison Berry wrote:
> On Nov 7, 2008, at 12:30 AM, Angela Byron wrote:
>> However. We should also think about "what if?" for create book page
>> permissions globally locked down to only docs team members.
>
> Overall I'm inclined to not cut it off entirely, but I'm definitely
> open to talking about that as an option. I'd really like other team
> members to weigh in on this. :-) My responses inline.
>
>> This would offer several benefits:
>>
>> 1. No more spam/test pages appearing in the getting started guide,
>> which
>> is most peoples' first impressions of Drupal's documentation. Not
>> cool.
>> Of course, your proposal would deal with this too, but it requires
>> code.
> Some code, not that much I'd say. Check if the person is on the team
> and, if not, form_alter the parent selector.
>
>> 2. .... Requiring non-docs team
>> members to add an issue for pages they'd like to add, with the text of
>> the page in there, would allow docs team members to review new
>> additions
>> and head these situations off at the pass (oh, actually this page
>> already exists at X. Why not edit that so that it includes the nice
>> clarifications you have here?). In this way it would sort of be like
>> the
>> patch contributor / module maintainer roles we have with development
>> projects.
> I feel like requiring people to make an issue means people simply
> won't do it at all and they'll just post on their personal blog,
> dispersing the info even further. According to handbook stats more
> pages are created by non-team members: "Of the 23 added, 16 were
> created by people not on the documentation team" I'd rather let people
> make the pages and then we do that same monitoring and feedback
> without making them do the hoop dance. It would be similar to patch
> review, but docs is not code and trying to make docs follow code
> processes and conventions is one of the "problems" we are currently
> trying to get away from honestly. ;-)
>
>> 3. With editing open to anyone, there is no longer a big incentive for
>> joining the docs team, I don't think.
> Well you still need to be on the team to use the doc format, which
> allows images.
>
>> While the docs team at the moment
>> is a powerhouse of awesomeness, over time people get busy with things,
>> and it's important to constantly have an influx of new blood. So
>> making
>> a "Ok, we trust you enough based on your edit contributions to give
>> you
>> create page rights now" thing might be a nice way to reward those who
>> are doing a great job.
> Fewer people create new pages than most other activity in docs. I do
> plan to make the doc team more "special" as we move forward but I
> guess I personally don't see that as much of a reward. Perhaps I'm
> wrong on that one though and so it is something to consider.
>
>
> - Addi (add1sun)
> --------------------------------------
> Join us at Do It With Drupal!
> A large scale, curated education event
> December 10-12, New Orleans
> http://www.doitwithdrupal.com
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/


From emmajane at xtrinsic.com  Fri Nov  7 16:28:59 2008
From: emmajane at xtrinsic.com (Emma Jane Hogbin)
Date: Fri, 07 Nov 2008 11:28:59 -0500
Subject: [documentation] Open editing/limiting creation?
In-Reply-To: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
References: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
Message-ID: <49146CCB.5000700@xtrinsic.com>

Addison Berry wrote:
> So, for now, I'm thinking about having a "holding" book. Basically we  
> could let people create new pages, but they would not get to choose  
> the location and it would go into a new book for this purpose. (We   

I would be +1 for this especially if they can recommend the place where
they think it ought to go (I am not always qualified to have an opinion
on where something should go, but it would be cool if I could help to
triage). In round XYZ of the redesign hopefully the "book/page
placement" will be less critical and it will be the use of appropriate
tags that will determine the placement of content.

emma :)

-- 
Emma Jane Hogbin, B.Sc.
Founder, xtrinsic
phone: (519) 371-2665
web: www.xtrinsic.com

From drupal at rocktreesky.com  Fri Nov  7 16:33:55 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Fri, 7 Nov 2008 11:33:55 -0500
Subject: [documentation] Open editing/limiting creation?
In-Reply-To: <49146CCB.5000700@xtrinsic.com>
References: <21D6E6A0-6582-4437-AC07-F2069CBB4092@rocktreesky.com>
	<49146CCB.5000700@xtrinsic.com>
Message-ID: <3E5A5BD0-F703-415D-95EE-8B864B7F303C@rocktreesky.com>

On Nov 7, 2008, at 11:28 AM, Emma Jane Hogbin wrote:

> Addison Berry wrote:
>> So, for now, I'm thinking about having a "holding" book. Basically we
>> could let people create new pages, but they would not get to choose
>> the location and it would go into a new book for this purpose. (We
>
> I would be +1 for this especially if they can recommend the place  
> where
> they think it ought to go (I am not always qualified to have an  
> opinion
> on where something should go, but it would be cool if I could help to
> triage). In round XYZ of the redesign hopefully the "book/page
> placement" will be less critical and it will be the use of appropriate
> tags that will determine the placement of content.

Agreed! Definitely looking forward to not having the hard structural  
issues we have now once we redesign. I agree on the suggestion and  
folks could put that in the log, but I'm not sure of the best way to  
solicit that info.

- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com


From drupal at rocktreesky.com  Fri Nov  7 20:53:22 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Fri, 7 Nov 2008 15:53:22 -0500
Subject: [documentation] IRC meeting summary for Nov. 7
Message-ID: <D71CC681-544D-4A13-80C2-436D8A831CC0@rocktreesky.com>

Group post at http://groups.drupal.org/node/16581

Copy of the post:

HUGE thanks to HansBKK for doing the summary this time round. Here is  
the full log: http://pastebin.com/f31e56f30 This is the summary for  
today's IRC meeting, with a few edits by me:

Meeting agenda: http://groups.drupal.org/node/16343

**Announcement**: ical feed on the group's upcoming events block

Assessing open editing
--------------------------------
Addy's thoughts: http://lists.drupal.org/pipermail/documentation/2008-November/006351.htm 
...

Consensus it's all good, non-docs team people making useful edits,  
it's quick to review, just check the diff. Decision: Leave it open,  
revisit if issues later on, no fixed review date.

**Ideas/thoughts/suggestions**
Most people don't know they can edit, suggestion to encourage them,  
along the lines of "This is a community contributed page. Please feel  
free to improve it with your edits."

Some issues re test posts, spam but not a lot. Creation of a sandbox  
for noobs to test post to, could link from the "Please do NOT post  
test pages. Drupal.org is a production site and you will not be able  
to delete content once you post it." text.

Also steer people to the issues queue to ask for help re creating pages.

Addy's idea on a "speed bump" on creating pages, parking them in a  
separate book to then be placed (by doc team members?): http://lists.drupal.org/pipermail/documentation/2008-November/006351.htm 
...

Idea to let the author suggest a place then let it be confirmed or  
moved rather than a separate book? Needs infrastructure. Don't want to  
create bottleneck or extra management overhead, leave for redesign.

Idea to display badges based on docteam membership, site maintainer  
role, help prioritize edits needing review.

Redesign ideas - would be great if only a small subset of people made  
"structural" changes.

a rating system on posts that flowed through to user ratings

Thank you messages and invitation to join the docs team - automated?

Tracking who's making a lot of edits recently.

Way to flag edits not yet reviewed - workflow system.

**Things to work on**
Recent edits page at http://drupal.org/handbook/updates needs a pager  
rather than just bumping the fixed number up, pending Views  
implementation.

Need to get one non-conflicting patch made and then Addy will poke the  
infra dudes.

Redesign
--------------------
Redesign effort, current doc-specific thread: http://groups.drupal.org/node/15965

Current design iteration: http://groups.drupal.org/node/16548

Other projects
--------------------
Work needed on getting some content into the D6 getting started guide,  
and getting the handbook style guide reviewed, refreshed and  
prominent, actually use it once we have something we like. Addy wants  
to work on templates,like README.txt files for module devs and various  
handook content like snippets.

We need to continue discussion and plan another meeting to line up  
projects.


**Summarizer's current hobby horse:**
Decision needed on the version "forking" issue, e.g. reorg the theme  
guides:
http://drupal.org/node/254947
http://groups.drupal.org/node/15965#comment-56550
http://drupal.org/node/105356#comment-1094732

Briefing doc on groups page, then vote?

Or if decision is yes, merge topics then next process is deciding  
specifically how to start the process.

- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com







From drupal at rocktreesky.com  Mon Nov 10 00:52:44 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Sun, 9 Nov 2008 19:52:44 -0500
Subject: [documentation] Schedule IRC meeting
References: <20081110003007.2546E16B4DE@www1.drupal.org>
Message-ID: <89FA817C-56BA-4FFF-B1F4-7509CE45458B@rocktreesky.com>


> add1sun has posted a Discussion at http://groups.drupal.org/node/16610
>
> Schedule IRC meeting
> ---------------
> The last meeting we covered a lot of ground and bounced around a  
> bunch of ideas. We didn't have much time to dive into new projects,  
> so let's set another one up soon. the meeting will be for 1 hour in  
> the #drupal-docs FreeNode channel.
> Here is the scheduling Doodle: http://doodle.com/u2xw6996qgkfd9yt  
> (Please respond to the Doodle with your preference by Thursday,  
> November 13.)
> Agenda:
>
> Announcements
> Limiting page creation? (let's please continue this discussion on  
> list and use the meeting to hash out remaining bits/action items)
> Next projects on radar:
>
> Getting started guide for D6 needs basic content completed
> Reorganizing the theme guides
> Reviewing/expanding the handbook style guide and creation of some  
> basic templates.
>


From drupal at rocktreesky.com  Thu Nov 13 22:32:29 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 13 Nov 2008 17:32:29 -0500
Subject: [documentation] Docs IRC meeting: Nov. 20
References: <20081113223035.79FFE16B4E9@www1.drupal.org>
Message-ID: <2E6D406A-0BB0-4830-A0E4-A4E6EB4ECF27@rocktreesky.com>

> http://groups.drupal.org/node/16719
>
> Docs IRC meeting: Nov. 20
> ---------------
> We've set the time for the next IRC meeting. The meeting will be for  
> 1 hour in the #drupal-docs FreeNode channel on Thursday, November  
> 20, 2008 at 1 p.m. EST (18:00 GMT, 10 a.m. PST).

> Agenda:
> Announcements
> Limiting page creation? (please continue this discussion on list and  
> use the meeting to hash out remaining bits/action items)
> Next projects on radar:
>   Getting started guide for D6 needs basic content completed
>   Reorganizing the theme guides
>   Reviewing/expanding the handbook style guide and creation of some  
> basic templates


- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com

From drupal at rocktreesky.com  Mon Nov 17 01:57:24 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Sun, 16 Nov 2008 20:57:24 -0500
Subject: [documentation] Open editing post not done yet
Message-ID: <310010B8-961B-4B01-8887-6AFD7F525209@rocktreesky.com>

Just FYI, I intended to do a post about the decision to continue the  
open editing, etc. (http://groups.drupal.org/node/16581) on Saturday  
(the end of the one month trial period) but I was out of town doing  
full days of training last week, as well as being sick, and have been  
trying to rest up since I got home. I will try to get to it by mid- 
week. I've got lots of work to catch up on and I'm still quite a bit  
sick so if anyone else feels like writing up a draft, please feel free  
to do so.

We should just refer to the original post where we talked about the  
trial, state that we will keep it open and maybe mention/link re: the  
ongoing ideas and discussions that came from it.

- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com







From hjames at gmail.com  Wed Nov 19 12:04:19 2008
From: hjames at gmail.com (Heather James)
Date: Wed, 19 Nov 2008 12:04:19 +0000
Subject: [documentation] Docs IRC meeting: Nov. 20
In-Reply-To: <2E6D406A-0BB0-4830-A0E4-A4E6EB4ECF27@rocktreesky.com>
References: <20081113223035.79FFE16B4E9@www1.drupal.org>
	<2E6D406A-0BB0-4830-A0E4-A4E6EB4ECF27@rocktreesky.com>
Message-ID: <9ff884cd0811190404t6fbf7417qae32d69f9a6e4a6d@mail.gmail.com>

Ooo... funny time... I will be just on my way home at that time, and
I'll arrive back a little late. So I should be popping on at 6.40? I
suppose that is kinda late.

I'll be on as nearlythere... if someone sees me pop on, can they post
the log somewhere to a pastebin, and I can get up to speed?

-heather

On Thu, Nov 13, 2008 at 10:32 PM, Addison Berry <drupal at rocktreesky.com> wrote:
>> http://groups.drupal.org/node/16719
>>
>> Docs IRC meeting: Nov. 20
>> ---------------
>> We've set the time for the next IRC meeting. The meeting will be for
>> 1 hour in the #drupal-docs FreeNode channel on Thursday, November
>> 20, 2008 at 1 p.m. EST (18:00 GMT, 10 a.m. PST).
>
>> Agenda:
>> Announcements
>> Limiting page creation? (please continue this discussion on list and
>> use the meeting to hash out remaining bits/action items)
>> Next projects on radar:
>>   Getting started guide for D6 needs basic content completed
>>   Reorganizing the theme guides
>>   Reviewing/expanding the handbook style guide and creation of some
>> basic templates
>
>
> - Addi (add1sun)
> --------------------------------------
> Join us at Do It With Drupal!
> A large scale, curated education event
> December 10-12, New Orleans
> http://www.doitwithdrupal.com
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/
>

From shai at content2zero.com  Wed Nov 19 22:59:37 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Wed, 19 Nov 2008 17:59:37 -0500
Subject: [documentation] Problem With One of the Main CVS Pages
Message-ID: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>

Hi gang,

This is about http://drupal.org/node/320

The title of the page is: *Checking out from the main repository

*The assumption on that page is that you want to check out HEAD. There is
one small section which says, "If you want to check out a specific version
of Drupal..."

I believe the assumption of the page should be opposite, that you want to
check out a specific version of Drupal. That is how you can check out the
latest stable release.

The use-case for checking out HEAD is for core committers or folks testing
patches to core. That is very important. However, I think the vast majority
of people wanting to get their feet wet in CVS (and therefore coming to this
handbook page) want to check out the latest *stable release* in order to
make it easier to upgrade the next time an updated stable release is
deployed.

I'd like to edit the page so that the primary instructions are for checking
out a specific version and the secondary instructions are for folks wanting
to checkout HEAD.

I thought this was a big enough change that I wanted to run it by others.

Thanks,

Shai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081119/6df71e73/attachment.htm 

From drupal at ryancross.com  Wed Nov 19 23:47:22 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Thu, 20 Nov 2008 10:47:22 +1100
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
Message-ID: <4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>

Disagree.

it is very standard practice for people jumping into a new open source
project to want to see HEAD (or trunk or whatever) or for people's first
interest in CVS is to see "what's coming". Most people that are interested
in checking out a specific version (like a stable version) are more advanced
or experienced with CVS already. Someone's first jump into CVS is not going
to be doing so in an effort to make upgrading easier.

My 2 cents at least.

On Thu, Nov 20, 2008 at 9:59 AM, Shai Gluskin <shai at content2zero.com> wrote:

> Hi gang,
>
> This is about http://drupal.org/node/320
>
> The title of the page is: *Checking out from the main repository
>
> *The assumption on that page is that you want to check out HEAD. There is
> one small section which says, "If you want to check out a specific version
> of Drupal..."
>
> I believe the assumption of the page should be opposite, that you want to
> check out a specific version of Drupal. That is how you can check out the
> latest stable release.
>
> The use-case for checking out HEAD is for core committers or folks testing
> patches to core. That is very important. However, I think the vast majority
> of people wanting to get their feet wet in CVS (and therefore coming to this
> handbook page) want to check out the latest *stable release* in order to
> make it easier to upgrade the next time an updated stable release is
> deployed.
>
> I'd like to edit the page so that the primary instructions are for checking
> out a specific version and the secondary instructions are for folks wanting
> to checkout HEAD.
>
> I thought this was a big enough change that I wanted to run it by others.
>
> Thanks,
>
> Shai
>
> --
> 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/20081120/23eb58e1/attachment.htm 

From Greg at growingventuresolutions.com  Thu Nov 20 00:04:51 2008
From: Greg at growingventuresolutions.com (Greg Knaddison - GVS)
Date: Wed, 19 Nov 2008 17:04:51 -0700
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
	<4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
Message-ID: <3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>

On Wed, Nov 19, 2008 at 4:47 PM, Ryan Cross <drupal at ryancross.com> wrote:
> Disagree.

Disagree.

>
> it is very standard practice for people jumping into a new open source
> project to want to see HEAD (or trunk or whatever) or for people's first
> interest in CVS is to see "what's coming". Most people that are interested
> in checking out a specific version (like a stable version) are more advanced
> or experienced with CVS already. Someone's first jump into CVS is not going
> to be doing so in an effort to make upgrading easier.

Maybe, but this is Drupal.  The installer in Drupal7 gets completely
broken on a pretty regular basis, and that's not a new thing - things
like that often happen in HEAD.  I agreed with Shai's proposal.  I
think it should primarily explain how to check out DRUPAL-6.  The only
drawback I can think of for doing that is it will require us to update
that page whenever a new version is released.

Regards,
Greg

From drupal-docs at webchick.net  Thu Nov 20 00:28:41 2008
From: drupal-docs at webchick.net (Angela Byron)
Date: Wed, 19 Nov 2008 19:28:41 -0500
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
	<4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
	<3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
Message-ID: <9CE57570-40A2-4931-A823-9357607DA0F4@webchick.net>


On 19-Nov-08, at 7:04 PM, Greg Knaddison - GVS wrote:

>> it is very standard practice for people jumping into a new open  
>> source
>> project to want to see HEAD (or trunk or whatever) or for people's  
>> first
>> interest in CVS is to see "what's coming". Most people that are  
>> interested
>> in checking out a specific version (like a stable version) are more  
>> advanced
>> or experienced with CVS already. Someone's first jump into CVS is  
>> not going
>> to be doing so in an effort to make upgrading easier.
>
> Maybe, but this is Drupal.  The installer in Drupal7 gets completely
> broken on a pretty regular basis, and that's not a new thing - things
> like that often happen in HEAD.

Hey, hey, hey! Quit spreading FUD! :P

Yes, the installer was broken for four hours last weekend. That's the  
first time the installer (or anything else on the major "critical  
path", for that matter) has been broken in HEAD since... a really long  
time. Thanks to automated testing, anything we have tests for is  
guaranteed to continue to stay working, and testing.drupal.org now  
ensures that even installer breakage never happens again. :)

That said, I agree with you on everything else. ;) +1 for making this  
page conform to user expectations.

-Angie


From drupal at ryancross.com  Thu Nov 20 00:53:50 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Thu, 20 Nov 2008 11:53:50 +1100
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <9CE57570-40A2-4931-A823-9357607DA0F4@webchick.net>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
	<4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
	<3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
	<9CE57570-40A2-4931-A823-9357607DA0F4@webchick.net>
Message-ID: <4e983be00811191653w1c916865i3be9e5e052c6ea62@mail.gmail.com>

On Thu, Nov 20, 2008 at 11:28 AM, Angela Byron <drupal-docs at webchick.net>wrote:

>
> On 19-Nov-08, at 7:04 PM, Greg Knaddison - GVS wrote:
>
> >
> > Maybe, but this is Drupal.
>

I'm not sure why we feel that Drupal has to be different from any other open
source project


>
> Hey, hey, hey! Quit spreading FUD! :P
>
> Yes, the installer was broken for four hours last weekend. That's the
> first time the installer (or anything else on the major "critical
> path", for that matter) has been broken in HEAD since... a really long
> time. Thanks to automated testing, anything we have tests for is
> guaranteed to continue to stay working, and testing.drupal.org now
> ensures that even installer breakage never happens again. :)
>

As Angie points out, with all the new testing available, I'm not sure why we
*wouldn't* want people focusing on HEAD.


>
> That said, I agree with you on everything else. ;) +1 for making this
> page conform to user expectations.


I'm not sure which side Angie falls on with this comment. I think most
people would expect instructions to check out HEAD. Plus, it is the more
natural first step in terms of CVS (less command parameters, etc).
Additionally, with the instructions for a specific version already available
I would not see any added benefit from reorganizing that page. I think this
is where our non-newbie/non-drupal-outsider bias is coming in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081120/7bf23759/attachment.htm 

From shai at content2zero.com  Thu Nov 20 01:11:50 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Wed, 19 Nov 2008 20:11:50 -0500
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
	<4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
	<3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
Message-ID: <9f68efb70811191711j23ccea29x35185f8252832a89@mail.gmail.com>

Greg, Ryan, and Documentors,

After reading Ryan and Greg's responses, the solution seems obvious... the
page shouldn't make *any* assumptions or determine priorities for use-cases.
It should be verbose with sections clearly labeled.

-- this is *how* you check out HEAD and this is *why* you'd want to check
out HEAD
-- this is *how* you check out a specific version and this is *why* you'd
want to check out a specific version

Greg wrote:

> The only drawback I can think of for doing that is it will require us to
> update that page whenever a new version is released.
>

I think as long as it is clear that the text you are providing as a sample
is a variable (replace "Drupal-6-6" with the most recent stable release.").

*Point of clarification needed:*
Greg, what you wrote makes me ask a further clarification. It has been my
experience that if you specify "DRUPAL-6" you'll get HEAD for Drupal 6. In
order to get the most recent stable release of Drupal 6, you'd have to
specify like this: DRUPAL-6-6.

Since D-6 is not under active development, it is true that the differences
between the latest stable release and HEAD will be minimal. However,it is
still better to use the stable release rather than HEAD, in my opinion. My
experience has been that if I checkout "DRUPAL-6" --- the admin pages,
update status etc. will show the version as "6.7" when the latest stable
release is 6.6. I find that disconcerting. Also, I don't know how Update
Status would respond when 6.7 actually does get released.

Greg -- am I missing something here?

*Another Point of clarification needed:*
The docs page in question mentions that there might be times when you'd want
to check out a release of Drupal (presumably HEAD) for a *specific date*. It
mentions no use-case. This is my guess: you are testing a patch and the
patch command requires that it be applied to the precise version that the
patch was created against. Given the sometimes slow work of volunteers, it
can easily happen that new versions of HEAD are created before folks have
had a chance to test a patch. Instead of requiring the patch-creater to keep
rolling against a new HEAD, testers can simply patch against a precise
version of HEAD that existed in the past. *Please confirm (or reject) that
I've got the use-case correct here.*

Thanks much,

Shai

On Wed, Nov 19, 2008 at 7:04 PM, Greg Knaddison - GVS <
Greg at growingventuresolutions.com> wrote:

> On Wed, Nov 19, 2008 at 4:47 PM, Ryan Cross <drupal at ryancross.com> wrote:
> > Disagree.
>
> Disagree.
>
> >
> > it is very standard practice for people jumping into a new open source
> > project to want to see HEAD (or trunk or whatever) or for people's first
> > interest in CVS is to see "what's coming". Most people that are
> interested
> > in checking out a specific version (like a stable version) are more
> advanced
> > or experienced with CVS already. Someone's first jump into CVS is not
> going
> > to be doing so in an effort to make upgrading easier.
>
> Maybe, but this is Drupal.  The installer in Drupal7 gets completely
> broken on a pretty regular basis, and that's not a new thing - things
> like that often happen in HEAD.  I agreed with Shai's proposal.  I
> think it should primarily explain how to check out DRUPAL-6.  The only
> drawback I can think of for doing that is it will require us to update
> that page whenever a new version is released.
>
> Regards,
> Greg
> --
> 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/20081119/75463992/attachment.htm 

From sepeck at gmail.com  Thu Nov 20 20:43:58 2008
From: sepeck at gmail.com (Steven Peck)
Date: Thu, 20 Nov 2008 12:43:58 -0800
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <9f68efb70811191711j23ccea29x35185f8252832a89@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
	<4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
	<3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
	<9f68efb70811191711j23ccea29x35185f8252832a89@mail.gmail.com>
Message-ID: <a151b5a00811201243g5979b42xb3e8131438dd2e3d@mail.gmail.com>

Why not add all three use cases and examples?  One for the HEAD
version of a release (Drupal 6) and another for a specific version
(Drupal 6.6) with the use cases you've just outlined?

That gives three use cases and examples

Development on the next generation
Drupal 7

Testing/bug fix on existing mainline stable branches (which is still
ongoing - see bug tracker)
Drupal 6 HEAD

CVS Pull of current production release for whatever
Drupal 6-6

These are not uncommon use case scenarios in our community and it does
no harm for people to be introduced and grow accustomed to such things
they may not have encountered before.

Steven


On Wed, Nov 19, 2008 at 5:11 PM, Shai Gluskin <shai at content2zero.com> wrote:
> Greg, Ryan, and Documentors,
>
> After reading Ryan and Greg's responses, the solution seems obvious... the
> page shouldn't make any assumptions or determine priorities for use-cases.
> It should be verbose with sections clearly labeled.
>
> -- this is how you check out HEAD and this is why you'd want to check out
> HEAD
> -- this is how you check out a specific version and this is why you'd want
> to check out a specific version
>
> Greg wrote:
>>
>> The only drawback I can think of for doing that is it will require us to
>> update that page whenever a new version is released.
>
> I think as long as it is clear that the text you are providing as a sample
> is a variable (replace "Drupal-6-6" with the most recent stable release.").
>
> Point of clarification needed:
> Greg, what you wrote makes me ask a further clarification. It has been my
> experience that if you specify "DRUPAL-6" you'll get HEAD for Drupal 6. In
> order to get the most recent stable release of Drupal 6, you'd have to
> specify like this: DRUPAL-6-6.
>
> Since D-6 is not under active development, it is true that the differences
> between the latest stable release and HEAD will be minimal. However,it is
> still better to use the stable release rather than HEAD, in my opinion. My
> experience has been that if I checkout "DRUPAL-6" --- the admin pages,
> update status etc. will show the version as "6.7" when the latest stable
> release is 6.6. I find that disconcerting. Also, I don't know how Update
> Status would respond when 6.7 actually does get released.
>
> Greg -- am I missing something here?
>
> Another Point of clarification needed:
> The docs page in question mentions that there might be times when you'd want
> to check out a release of Drupal (presumably HEAD) for a specific date. It
> mentions no use-case. This is my guess: you are testing a patch and the
> patch command requires that it be applied to the precise version that the
> patch was created against. Given the sometimes slow work of volunteers, it
> can easily happen that new versions of HEAD are created before folks have
> had a chance to test a patch. Instead of requiring the patch-creater to keep
> rolling against a new HEAD, testers can simply patch against a precise
> version of HEAD that existed in the past. Please confirm (or reject) that
> I've got the use-case correct here.
>
> Thanks much,
>
> Shai
>
> On Wed, Nov 19, 2008 at 7:04 PM, Greg Knaddison - GVS
> <Greg at growingventuresolutions.com> wrote:
>>
>> On Wed, Nov 19, 2008 at 4:47 PM, Ryan Cross <drupal at ryancross.com> wrote:
>> > Disagree.
>>
>> Disagree.
>>
>> >
>> > it is very standard practice for people jumping into a new open source
>> > project to want to see HEAD (or trunk or whatever) or for people's first
>> > interest in CVS is to see "what's coming". Most people that are
>> > interested
>> > in checking out a specific version (like a stable version) are more
>> > advanced
>> > or experienced with CVS already. Someone's first jump into CVS is not
>> > going
>> > to be doing so in an effort to make upgrading easier.
>>
>> Maybe, but this is Drupal.  The installer in Drupal7 gets completely
>> broken on a pretty regular basis, and that's not a new thing - things
>> like that often happen in HEAD.  I agreed with Shai's proposal.  I
>> think it should primarily explain how to check out DRUPAL-6.  The only
>> drawback I can think of for doing that is it will require us to update
>> that page whenever a new version is released.
>>
>> Regards,
>> Greg
>> --
>> 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 shai at content2zero.com  Thu Nov 20 20:57:58 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Thu, 20 Nov 2008 15:57:58 -0500
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <a151b5a00811201243g5979b42xb3e8131438dd2e3d@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
	<4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
	<3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
	<9f68efb70811191711j23ccea29x35185f8252832a89@mail.gmail.com>
	<a151b5a00811201243g5979b42xb3e8131438dd2e3d@mail.gmail.com>
Message-ID: <9f68efb70811201257r29c42d0bv35eb08c420a67ae2@mail.gmail.com>

Steve,

Yes, you've summarized exactly what I intend to do.

Shai

On Thu, Nov 20, 2008 at 3:43 PM, Steven Peck <sepeck at gmail.com> wrote:

> Why not add all three use cases and examples?  One for the HEAD
> version of a release (Drupal 6) and another for a specific version
> (Drupal 6.6) with the use cases you've just outlined?
>
> That gives three use cases and examples
>
> Development on the next generation
> Drupal 7
>
> Testing/bug fix on existing mainline stable branches (which is still
> ongoing - see bug tracker)
> Drupal 6 HEAD
>
> CVS Pull of current production release for whatever
> Drupal 6-6
>
> These are not uncommon use case scenarios in our community and it does
> no harm for people to be introduced and grow accustomed to such things
> they may not have encountered before.
>
> Steven
>
>
> On Wed, Nov 19, 2008 at 5:11 PM, Shai Gluskin <shai at content2zero.com>
> wrote:
> > Greg, Ryan, and Documentors,
> >
> > After reading Ryan and Greg's responses, the solution seems obvious...
> the
> > page shouldn't make any assumptions or determine priorities for
> use-cases.
> > It should be verbose with sections clearly labeled.
> >
> > -- this is how you check out HEAD and this is why you'd want to check out
> > HEAD
> > -- this is how you check out a specific version and this is why you'd
> want
> > to check out a specific version
> >
> > Greg wrote:
> >>
> >> The only drawback I can think of for doing that is it will require us to
> >> update that page whenever a new version is released.
> >
> > I think as long as it is clear that the text you are providing as a
> sample
> > is a variable (replace "Drupal-6-6" with the most recent stable
> release.").
> >
> > Point of clarification needed:
> > Greg, what you wrote makes me ask a further clarification. It has been my
> > experience that if you specify "DRUPAL-6" you'll get HEAD for Drupal 6.
> In
> > order to get the most recent stable release of Drupal 6, you'd have to
> > specify like this: DRUPAL-6-6.
> >
> > Since D-6 is not under active development, it is true that the
> differences
> > between the latest stable release and HEAD will be minimal. However,it is
> > still better to use the stable release rather than HEAD, in my opinion.
> My
> > experience has been that if I checkout "DRUPAL-6" --- the admin pages,
> > update status etc. will show the version as "6.7" when the latest stable
> > release is 6.6. I find that disconcerting. Also, I don't know how Update
> > Status would respond when 6.7 actually does get released.
> >
> > Greg -- am I missing something here?
> >
> > Another Point of clarification needed:
> > The docs page in question mentions that there might be times when you'd
> want
> > to check out a release of Drupal (presumably HEAD) for a specific date.
> It
> > mentions no use-case. This is my guess: you are testing a patch and the
> > patch command requires that it be applied to the precise version that the
> > patch was created against. Given the sometimes slow work of volunteers,
> it
> > can easily happen that new versions of HEAD are created before folks have
> > had a chance to test a patch. Instead of requiring the patch-creater to
> keep
> > rolling against a new HEAD, testers can simply patch against a precise
> > version of HEAD that existed in the past. Please confirm (or reject) that
> > I've got the use-case correct here.
> >
> > Thanks much,
> >
> > Shai
> >
> > On Wed, Nov 19, 2008 at 7:04 PM, Greg Knaddison - GVS
> > <Greg at growingventuresolutions.com> wrote:
> >>
> >> On Wed, Nov 19, 2008 at 4:47 PM, Ryan Cross <drupal at ryancross.com>
> wrote:
> >> > Disagree.
> >>
> >> Disagree.
> >>
> >> >
> >> > it is very standard practice for people jumping into a new open source
> >> > project to want to see HEAD (or trunk or whatever) or for people's
> first
> >> > interest in CVS is to see "what's coming". Most people that are
> >> > interested
> >> > in checking out a specific version (like a stable version) are more
> >> > advanced
> >> > or experienced with CVS already. Someone's first jump into CVS is not
> >> > going
> >> > to be doing so in an effort to make upgrading easier.
> >>
> >> Maybe, but this is Drupal.  The installer in Drupal7 gets completely
> >> broken on a pretty regular basis, and that's not a new thing - things
> >> like that often happen in HEAD.  I agreed with Shai's proposal.  I
> >> think it should primarily explain how to check out DRUPAL-6.  The only
> >> drawback I can think of for doing that is it will require us to update
> >> that page whenever a new version is released.
> >>
> >> Regards,
> >> Greg
> >> --
> >> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081120/a11b7312/attachment-0001.htm 

From shai at content2zero.com  Thu Nov 20 21:02:38 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Thu, 20 Nov 2008 16:02:38 -0500
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <9f68efb70811201257r29c42d0bv35eb08c420a67ae2@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
	<4e983be00811191547r196dec72pd3c81de1761bdd35@mail.gmail.com>
	<3861c6770811191604m7225b377id4b7334cb5fdb28c@mail.gmail.com>
	<9f68efb70811191711j23ccea29x35185f8252832a89@mail.gmail.com>
	<a151b5a00811201243g5979b42xb3e8131438dd2e3d@mail.gmail.com>
	<9f68efb70811201257r29c42d0bv35eb08c420a67ae2@mail.gmail.com>
Message-ID: <9f68efb70811201302obe47283tfecd45d695ecb7b0@mail.gmail.com>

Okay Louie,

I've signed you up for the Haftarah for this Shabbat.

Thanks,

Shai

On Thu, Nov 20, 2008 at 3:57 PM, Shai Gluskin <shai at content2zero.com> wrote:

> Steve,
>
> Yes, you've summarized exactly what I intend to do.
>
> Shai
>
>
> On Thu, Nov 20, 2008 at 3:43 PM, Steven Peck <sepeck at gmail.com> wrote:
>
>> Why not add all three use cases and examples?  One for the HEAD
>> version of a release (Drupal 6) and another for a specific version
>> (Drupal 6.6) with the use cases you've just outlined?
>>
>> That gives three use cases and examples
>>
>> Development on the next generation
>> Drupal 7
>>
>> Testing/bug fix on existing mainline stable branches (which is still
>> ongoing - see bug tracker)
>> Drupal 6 HEAD
>>
>> CVS Pull of current production release for whatever
>> Drupal 6-6
>>
>> These are not uncommon use case scenarios in our community and it does
>> no harm for people to be introduced and grow accustomed to such things
>> they may not have encountered before.
>>
>> Steven
>>
>>
>> On Wed, Nov 19, 2008 at 5:11 PM, Shai Gluskin <shai at content2zero.com>
>> wrote:
>> > Greg, Ryan, and Documentors,
>> >
>> > After reading Ryan and Greg's responses, the solution seems obvious...
>> the
>> > page shouldn't make any assumptions or determine priorities for
>> use-cases.
>> > It should be verbose with sections clearly labeled.
>> >
>> > -- this is how you check out HEAD and this is why you'd want to check
>> out
>> > HEAD
>> > -- this is how you check out a specific version and this is why you'd
>> want
>> > to check out a specific version
>> >
>> > Greg wrote:
>> >>
>> >> The only drawback I can think of for doing that is it will require us
>> to
>> >> update that page whenever a new version is released.
>> >
>> > I think as long as it is clear that the text you are providing as a
>> sample
>> > is a variable (replace "Drupal-6-6" with the most recent stable
>> release.").
>> >
>> > Point of clarification needed:
>> > Greg, what you wrote makes me ask a further clarification. It has been
>> my
>> > experience that if you specify "DRUPAL-6" you'll get HEAD for Drupal 6.
>> In
>> > order to get the most recent stable release of Drupal 6, you'd have to
>> > specify like this: DRUPAL-6-6.
>> >
>> > Since D-6 is not under active development, it is true that the
>> differences
>> > between the latest stable release and HEAD will be minimal. However,it
>> is
>> > still better to use the stable release rather than HEAD, in my opinion.
>> My
>> > experience has been that if I checkout "DRUPAL-6" --- the admin pages,
>> > update status etc. will show the version as "6.7" when the latest stable
>> > release is 6.6. I find that disconcerting. Also, I don't know how Update
>> > Status would respond when 6.7 actually does get released.
>> >
>> > Greg -- am I missing something here?
>> >
>> > Another Point of clarification needed:
>> > The docs page in question mentions that there might be times when you'd
>> want
>> > to check out a release of Drupal (presumably HEAD) for a specific date.
>> It
>> > mentions no use-case. This is my guess: you are testing a patch and the
>> > patch command requires that it be applied to the precise version that
>> the
>> > patch was created against. Given the sometimes slow work of volunteers,
>> it
>> > can easily happen that new versions of HEAD are created before folks
>> have
>> > had a chance to test a patch. Instead of requiring the patch-creater to
>> keep
>> > rolling against a new HEAD, testers can simply patch against a precise
>> > version of HEAD that existed in the past. Please confirm (or reject)
>> that
>> > I've got the use-case correct here.
>> >
>> > Thanks much,
>> >
>> > Shai
>> >
>> > On Wed, Nov 19, 2008 at 7:04 PM, Greg Knaddison - GVS
>> > <Greg at growingventuresolutions.com> wrote:
>> >>
>> >> On Wed, Nov 19, 2008 at 4:47 PM, Ryan Cross <drupal at ryancross.com>
>> wrote:
>> >> > Disagree.
>> >>
>> >> Disagree.
>> >>
>> >> >
>> >> > it is very standard practice for people jumping into a new open
>> source
>> >> > project to want to see HEAD (or trunk or whatever) or for people's
>> first
>> >> > interest in CVS is to see "what's coming". Most people that are
>> >> > interested
>> >> > in checking out a specific version (like a stable version) are more
>> >> > advanced
>> >> > or experienced with CVS already. Someone's first jump into CVS is not
>> >> > going
>> >> > to be doing so in an effort to make upgrading easier.
>> >>
>> >> Maybe, but this is Drupal.  The installer in Drupal7 gets completely
>> >> broken on a pretty regular basis, and that's not a new thing - things
>> >> like that often happen in HEAD.  I agreed with Shai's proposal.  I
>> >> think it should primarily explain how to check out DRUPAL-6.  The only
>> >> drawback I can think of for doing that is it will require us to update
>> >> that page whenever a new version is released.
>> >>
>> >> Regards,
>> >> Greg
>> >> --
>> >> 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/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081120/e8e2e2c2/attachment.htm 

From drupal at rocktreesky.com  Thu Nov 20 23:42:02 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 20 Nov 2008 18:42:02 -0500
Subject: [documentation] Proposal to deprecate the docs mailing list
References: <20081120233004.63A3C16B54E@www1.drupal.org>
Message-ID: <CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>

> So this is an issue that has been kicking around in my head for a  
> while. It was raised briefly earlier this year (http://lists.drupal.org/pipermail/documentation/2008-March/thread.html#5900 
> ) on the list and it was decided to stick with the mailing list. I  
> raised it again today during our IRC meeting to get a general pulse.  
> So, I'm going to lay it all out and see what the larger team thinks.
>
> I am proposing that we deprecate the documentation mailing list and  
> use groups.drupal.org for our discussions instead. In order to not  
> have conversations happening in two places we need to have one  
> definitive "discussion" venue. Due to this, the current docs group  
> is "read-only." To make it read-only we have to limit who can  
> actually become a member of the group. Limiting membership like this  
> severely hampers our use of all the tools that g.d.o could offer us.
>
> If we allowed membership and free posting on the g.d.o group, we  
> would:
> - Still have email notifications of all discussions.
> - Be able to use wiki posts to collaborate on one living document  
> rather than having to attach separate iterations to an issue in the  
> queue.
> - Read threads all on one page rather than have to page through the  
> mailman archive.
> - Organize and categorize discussions to make it easier to find  
> areas of interest.
> - Replying to old threads that you didn't actually receive in email  
> is clear and straightforward - just leave a new comment. (How to  
> respond to archived mail threads is not an apparent thing.)
>
> The only advantage that the mailing list provides that the group  
> does not, is the ability to reply to a thread directly from your  
> email. I feel that losing this feature is worth the advantages we  
> would gain by shifting to g.d.o. I feel that this is true for  
> actually collaborating as a team and to make it easier for new users  
> to join in.
>
> I am posting this to the mailing list as well as posting on g.d.o  
> with comments turned on. This is one conversation that I'd like to  
> see discussed wherever folks feel most comfortable.



- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com

From hjames at gmail.com  Fri Nov 21 00:03:29 2008
From: hjames at gmail.com (Heather)
Date: Fri, 21 Nov 2008 00:03:29 +0000
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org><CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
Message-ID: <487414476-1227225990-cardhu_decombobulator_blackberry.rim.net-2067678750-@bxe070.bisx.produk.on.blackberry>


Okey, I am strongly in favor of working with the team on a wiki page to focus on, for example, a review of the getting started guide. Being able to keep a list, suggest reordering, etc, through wiki its superior. 

Also, having the mailing list, when there is so much productive activity on g.d.o feels a bit like a back channel to me, which goes counter to the transparent open policies of Drupal. 

But... Here I am, I have access through my phone and I'm responding via email. That's the irony. Wish we could have it both ways. Hmm.. Wish I could browse g.d.o on my phone, but that's another problem!

Can we sort of turn on wiki pages in the group, and see how it goes? Hey if you used g.d.o you could make a poll. Heh. 

- Heather


-----Original Message-----
From: Addison Berry <drupal at rocktreesky.com>

Date: Thu, 20 Nov 2008 18:42:02 
To: <documentation at drupal.org>
Subject: [documentation] Proposal to deprecate the docs mailing list


> So this is an issue that has been kicking around in my head for a  
> while. It was raised briefly earlier this year (http://lists.drupal.org/pipermail/documentation/2008-March/thread.html#5900 
> ) on the list and it was decided to stick with the mailing list. I  
> raised it again today during our IRC meeting to get a general pulse.  
> So, I'm going to lay it all out and see what the larger team thinks.
>
> I am proposing that we deprecate the documentation mailing list and  
> use groups.drupal.org for our discussions instead. In order to not  
> have conversations happening in two places we need to have one  
> definitive "discussion" venue. Due to this, the current docs group  
> is "read-only." To make it read-only we have to limit who can  
> actually become a member of the group. Limiting membership like this  
> severely hampers our use of all the tools that g.d.o could offer us.
>
> If we allowed membership and free posting on the g.d.o group, we  
> would:
> - Still have email notifications of all discussions.
> - Be able to use wiki posts to collaborate on one living document  
> rather than having to attach separate iterations to an issue in the  
> queue.
> - Read threads all on one page rather than have to page through the  
> mailman archive.
> - Organize and categorize discussions to make it easier to find  
> areas of interest.
> - Replying to old threads that you didn't actually receive in email  
> is clear and straightforward - just leave a new comment. (How to  
> respond to archived mail threads is not an apparent thing.)
>
> The only advantage that the mailing list provides that the group  
> does not, is the ability to reply to a thread directly from your  
> email. I feel that losing this feature is worth the advantages we  
> would gain by shifting to g.d.o. I feel that this is true for  
> actually collaborating as a team and to make it easier for new users  
> to join in.
>
> I am posting this to the mailing list as well as posting on g.d.o  
> with comments turned on. This is one conversation that I'd like to  
> see discussed wherever folks feel most comfortable.



- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/

From drupal at ryancross.com  Fri Nov 21 00:13:46 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Fri, 21 Nov 2008 11:13:46 +1100
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <487414476-1227225990-cardhu_decombobulator_blackberry.rim.net-2067678750-@bxe070.bisx.produk.on.blackberry>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<487414476-1227225990-cardhu_decombobulator_blackberry.rim.net-2067678750-@bxe070.bisx.produk.on.blackberry>
Message-ID: <4e983be00811201613k753a11f8ob17b3ae965a26b45@mail.gmail.com>

Well, i can see the benefits to using g.d.o but currently we are not really
using it, so its hard to see whether or not people will rally to it.

It might seem small, but one of the biggest drawbacks is that in order to
reply to a message I would have to leave my email, then open a browser or
tab, then log in to g.d.o, then potentially need to find the thread, then
post my comment. This is very burdensome when just wantign to make a short
response or the occasional "+1" on a topic.

I am also realizing now that I am replying via email, so whatever that is
worth...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081121/91b36f86/attachment-0001.htm 

From shai at content2zero.com  Fri Nov 21 00:17:33 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Thu, 20 Nov 2008 19:17:33 -0500
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <487414476-1227225990-cardhu_decombobulator_blackberry.rim.net-2067678750-@bxe070.bisx.produk.on.blackberry>
References: <20081120233004.63A3C16B54E@www1.drupal.org><CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<487414476-1227225990-cardhu_decombobulator_blackberry.rim.net-2067678750-@bxe070.bisx.produk.on.blackberry>
Message-ID: <42099E32-4449-40EE-8F58-DD19EF1E819D@content2zero.com>

+1

Shai

Shai Gluskin

On Nov 20, 2008, at 7:03 PM, "Heather" <hjames at gmail.com> wrote:

>
> Okey, I am strongly in favor of working with the team on a wiki page  
> to focus on, for example, a review of the getting started guide.  
> Being able to keep a list, suggest reordering, etc, through wiki its  
> superior.
>
> Also, having the mailing list, when there is so much productive  
> activity on g.d.o feels a bit like a back channel to me, which goes  
> counter to the transparent open policies of Drupal.
>
> But... Here I am, I have access through my phone and I'm responding  
> via email. That's the irony. Wish we could have it both ways. Hmm..  
> Wish I could browse g.d.o on my phone, but that's another problem!
>
> Can we sort of turn on wiki pages in the group, and see how it goes?  
> Hey if you used g.d.o you could make a poll. Heh.
>
> - Heather
>
>
> -----Original Message-----
> From: Addison Berry <drupal at rocktreesky.com>
>
> Date: Thu, 20 Nov 2008 18:42:02
> To: <documentation at drupal.org>
> Subject: [documentation] Proposal to deprecate the docs mailing list
>
>
>> So this is an issue that has been kicking around in my head for a
>> while. It was raised briefly earlier this year (http://lists.drupal.org/pipermail/documentation/2008-March/thread.html#5900
>> ) on the list and it was decided to stick with the mailing list. I
>> raised it again today during our IRC meeting to get a general pulse.
>> So, I'm going to lay it all out and see what the larger team thinks.
>>
>> I am proposing that we deprecate the documentation mailing list and
>> use groups.drupal.org for our discussions instead. In order to not
>> have conversations happening in two places we need to have one
>> definitive "discussion" venue. Due to this, the current docs group
>> is "read-only." To make it read-only we have to limit who can
>> actually become a member of the group. Limiting membership like this
>> severely hampers our use of all the tools that g.d.o could offer us.
>>
>> If we allowed membership and free posting on the g.d.o group, we
>> would:
>> - Still have email notifications of all discussions.
>> - Be able to use wiki posts to collaborate on one living document
>> rather than having to attach separate iterations to an issue in the
>> queue.
>> - Read threads all on one page rather than have to page through the
>> mailman archive.
>> - Organize and categorize discussions to make it easier to find
>> areas of interest.
>> - Replying to old threads that you didn't actually receive in email
>> is clear and straightforward - just leave a new comment. (How to
>> respond to archived mail threads is not an apparent thing.)
>>
>> The only advantage that the mailing list provides that the group
>> does not, is the ability to reply to a thread directly from your
>> email. I feel that losing this feature is worth the advantages we
>> would gain by shifting to g.d.o. I feel that this is true for
>> actually collaborating as a team and to make it easier for new users
>> to join in.
>>
>> I am posting this to the mailing list as well as posting on g.d.o
>> with comments turned on. This is one conversation that I'd like to
>> see discussed wherever folks feel most comfortable.
>
>
>
> - Addi (add1sun)
> --------------------------------------
> Join us at Do It With Drupal!
> A large scale, curated education event
> December 10-12, New Orleans
> http://www.doitwithdrupal.com
> --
> 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 joshua at brauerranch.com  Fri Nov 21 00:40:39 2008
From: joshua at brauerranch.com (Joshua Brauer)
Date: Thu, 20 Nov 2008 17:40:39 -0700
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
Message-ID: <36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>

Comments below. I'm NOT a fan of the idea of deprecating the mailing  
list for the reasons below.

On Nov 20, 2008, at 4:42 PM, Addison Berry wrote:
>> [...]
>>
>> If we allowed membership and free posting on the g.d.o group, we
>> would:
>> - Still have email notifications of all discussions.

Notifications from g.d.o are a real mixed bag. First of all they are  
*notifications* which means I can't participate from email using the  
tools that provide the ability to create drafts, save drafts and  
can't, as in this example, easily note which part of something is  
being discussed. Having email fill up with notifications of yet  
another place to go look at information is sub-optimal and greatly  
increases (as it gets read twice) the work involved in participating.


>>
>> - Be able to use wiki posts to collaborate on one living document
>> rather than having to attach separate iterations to an issue in the
>> queue.

In short Wikis on g.d.o are broken. At the start of Summer of Code we  
talked a little about fixing it but there is a reason (that I don't  
recall) we were told no. In short a Wiki page with no editing history,  
which is what the vast majority of us see, is much worse than a  
threaded discussion or iterations being attached to an issue. A wiki  
page without history presents very little chance of understanding what  
the arguments for or against an issue were or how the decision was  
made. As it is Wikis on g.d.o make things opaque not transparent. The  
other thing with the wiki model when it does work, is there is very  
little place to really explain a change, or to propose a change and  
discuss without making it.

>>
>> - Read threads all on one page rather than have to page through the
>> mailman archive.

On the other hand it means going somewhere else to read the threads.  
On the other hand as it is now I can read the threads on one page in  
my email box. And I can effectively search and use the information in  
the same ways as other areas of the Drupal community. It's not a  
matter of "oh that's doc so it's on the web" but that other issue  
which was discussed was development so it's in email.



>>
>> - Organize and categorize discussions to make it easier to find
>> areas of interest.

I find the threading of mail much easier to follow. In a system with  
comments the branches of comments fork and frequently go in multiple  
directions. So there is much more scrolling, jumping and having to  
reply in multiple places to follow one thread.

>>
>> - Replying to old threads that you didn't actually receive in email
>> is clear and straightforward - just leave a new comment. (How to
>> respond to archived mail threads is not an apparent thing.)
>>
This is the only good point about the web in my opinion. But even this  
is marginal. If I'm new and I want to revisit a thread there is  
nothing wrong with opening a new email thread. If on the other hand I  
comment on a long-past web page few people are really likely to pay a  
lot of attention.

>> The only advantage that the mailing list provides that the group
>> does not, is the ability to reply to a thread directly from your
>> email. I feel that losing this feature is worth the advantages we
>> would gain by shifting to g.d.o. I feel that this is true for
>> actually collaborating as a team and to make it easier for new users
>> to join in.


I actually think this is the opposite. Many users on the web are very  
comfortable with email lists. Mailing lists are also much easier to  
lurk and get comfortable on. It's certainly *possible* to do this on a  
web page, but it takes effort. And if one has to consistently revisit  
the same wiki page to see what's changed even more so... However  
something that is in email makes it much easier to pick up wherever  
one is and read and even respond.

Oh and finally as a frequent flyer... g.d.o doesn't work nearly as  
well on a plane as email lists.

In sort my vote would be that the email list should remain the primary  
workspace and wiki pages, when appropriate, can serve a valuable  
purpose as a supplement.

Thanks,
Josh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1592 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/documentation/attachments/20081120/fc30854e/attachment.bin 

From drupal at rocktreesky.com  Fri Nov 21 01:15:52 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 20 Nov 2008 20:15:52 -0500
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
Message-ID: <7D50F80A-9F67-401D-A216-EDD4C56CECB4@rocktreesky.com>


On Nov 20, 2008, at 7:40 PM, Joshua Brauer wrote:
>>>
>
> In sort my vote would be that the email list should remain the  
> primary workspace and wiki pages, when appropriate, can serve a  
> valuable purpose as a supplement.

Well the main problem is that we can't "occasionally" use wiki pages  
as a supplement. You have to be a member to use a wiki page and if we  
open up membership then folks can create any kind of group content  
which will end up spawning some discussions on g.d.o and some on the  
mail list.

I think the bottom line, no matter what we do is that there will  
always be a group that prefers either email lists or web based. I'm  
not sure how to accommodate everyone (we can't). A lot of feedback  
that I get when trying to recruit new members to our discussions  
though is that they don't want to join an email list. Or even if they  
are willing to, it is very frustrating to tell new members "oh yeah,  
we are talking about that. you can read up on this nasty piper mail  
interface and then join the mail list and create a new thread  
referring to the archive version that you read." So, um, how many  
people have you seen jump into our discussions like that? *me hears  
crickets chirp* That is seriously one of my main motivations, in terms  
of getting new people involved, that I have to deal with all the time  
when talking to people who want to help out.

I do get the strong arguments in favor of the mail list and no, g.d.o  
is not ideal, but I do still feel that the advantages  of g.d.o are  
greater in terms of collaboration and getting new people involved.  
Unfortunately it is also hard to reach out to get the opinion of  
people who don't use the mail list since, de facto, they have limited  
ways of getting involved in discussions. If they don't subscribe to  
the RSS feed for the doc group, they have no idea this discussion is  
even happening right now. That seems pretty limiting in and of itself.

- Addi

From catch56 at googlemail.com  Fri Nov 21 01:18:45 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Fri, 21 Nov 2008 01:18:45 +0000
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <7D50F80A-9F67-401D-A216-EDD4C56CECB4@rocktreesky.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
	<7D50F80A-9F67-401D-A216-EDD4C56CECB4@rocktreesky.com>
Message-ID: <fa5724270811201718t4875c6b8x5aaced4555b850b3@mail.gmail.com>

I already answered on groups ;)

However for those who still want e-mail, I think it would be worth filing
feature requests on groups for two things - full messages in notifications,
and mailhandler to allow people to reply to notifications via e-mail and
have those posted on groups. Both would involve some work, but that would
then give people a complete choice - and I'm sure it's not only the docs
team which feels a need for this.

Nat

On Fri, Nov 21, 2008 at 1:15 AM, Addison Berry <drupal at rocktreesky.com>wrote:

>
> On Nov 20, 2008, at 7:40 PM, Joshua Brauer wrote:
> >>>
> >
> > In sort my vote would be that the email list should remain the
> > primary workspace and wiki pages, when appropriate, can serve a
> > valuable purpose as a supplement.
>
> Well the main problem is that we can't "occasionally" use wiki pages
> as a supplement. You have to be a member to use a wiki page and if we
> open up membership then folks can create any kind of group content
> which will end up spawning some discussions on g.d.o and some on the
> mail list.
>
> I think the bottom line, no matter what we do is that there will
> always be a group that prefers either email lists or web based. I'm
> not sure how to accommodate everyone (we can't). A lot of feedback
> that I get when trying to recruit new members to our discussions
> though is that they don't want to join an email list. Or even if they
> are willing to, it is very frustrating to tell new members "oh yeah,
> we are talking about that. you can read up on this nasty piper mail
> interface and then join the mail list and create a new thread
> referring to the archive version that you read." So, um, how many
> people have you seen jump into our discussions like that? *me hears
> crickets chirp* That is seriously one of my main motivations, in terms
> of getting new people involved, that I have to deal with all the time
> when talking to people who want to help out.
>
> I do get the strong arguments in favor of the mail list and no, g.d.o
> is not ideal, but I do still feel that the advantages  of g.d.o are
> greater in terms of collaboration and getting new people involved.
> Unfortunately it is also hard to reach out to get the opinion of
> people who don't use the mail list since, de facto, they have limited
> ways of getting involved in discussions. If they don't subscribe to
> the RSS feed for the doc group, they have no idea this discussion is
> even happening right now. That seems pretty limiting in and of itself.
>
> - Addi
> --
> 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/20081121/81b55ee2/attachment.htm 

From sepeck at gmail.com  Fri Nov 21 01:40:25 2008
From: sepeck at gmail.com (Steven Peck)
Date: Thu, 20 Nov 2008 17:40:25 -0800
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <fa5724270811201718t4875c6b8x5aaced4555b850b3@mail.gmail.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
	<7D50F80A-9F67-401D-A216-EDD4C56CECB4@rocktreesky.com>
	<fa5724270811201718t4875c6b8x5aaced4555b850b3@mail.gmail.com>
Message-ID: <a151b5a00811201740u75b4e663x7cf6ec3abd95c74@mail.gmail.com>

My reasons from before still stand.  I rarely visit group at all.  I
found it alien to my work flow process in the past and while I will
look again, I do not see that core facet changing for me.

Up to you.

On Thu, Nov 20, 2008 at 5:18 PM, Nathaniel Catchpole
<catch56 at googlemail.com> wrote:
> I already answered on groups ;)
>
> However for those who still want e-mail, I think it would be worth filing
> feature requests on groups for two things - full messages in notifications,
> and mailhandler to allow people to reply to notifications via e-mail and
> have those posted on groups. Both would involve some work, but that would
> then give people a complete choice - and I'm sure it's not only the docs
> team which feels a need for this.
>
> Nat
>
> On Fri, Nov 21, 2008 at 1:15 AM, Addison Berry <drupal at rocktreesky.com>
> wrote:
>>
>> On Nov 20, 2008, at 7:40 PM, Joshua Brauer wrote:
>> >>>
>> >
>> > In sort my vote would be that the email list should remain the
>> > primary workspace and wiki pages, when appropriate, can serve a
>> > valuable purpose as a supplement.
>>
>> Well the main problem is that we can't "occasionally" use wiki pages
>> as a supplement. You have to be a member to use a wiki page and if we
>> open up membership then folks can create any kind of group content
>> which will end up spawning some discussions on g.d.o and some on the
>> mail list.
>>
>> I think the bottom line, no matter what we do is that there will
>> always be a group that prefers either email lists or web based. I'm
>> not sure how to accommodate everyone (we can't). A lot of feedback
>> that I get when trying to recruit new members to our discussions
>> though is that they don't want to join an email list. Or even if they
>> are willing to, it is very frustrating to tell new members "oh yeah,
>> we are talking about that. you can read up on this nasty piper mail
>> interface and then join the mail list and create a new thread
>> referring to the archive version that you read." So, um, how many
>> people have you seen jump into our discussions like that? *me hears
>> crickets chirp* That is seriously one of my main motivations, in terms
>> of getting new people involved, that I have to deal with all the time
>> when talking to people who want to help out.
>>
>> I do get the strong arguments in favor of the mail list and no, g.d.o
>> is not ideal, but I do still feel that the advantages  of g.d.o are
>> greater in terms of collaboration and getting new people involved.
>> Unfortunately it is also hard to reach out to get the opinion of
>> people who don't use the mail list since, de facto, they have limited
>> ways of getting involved in discussions. If they don't subscribe to
>> the RSS feed for the doc group, they have no idea this discussion is
>> even happening right now. That seems pretty limiting in and of itself.
>>
>> - Addi
>> --
>> 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 ryancross.com  Fri Nov 21 01:58:40 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Fri, 21 Nov 2008 12:58:40 +1100
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <7D50F80A-9F67-401D-A216-EDD4C56CECB4@rocktreesky.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
	<7D50F80A-9F67-401D-A216-EDD4C56CECB4@rocktreesky.com>
Message-ID: <4e983be00811201758r26cc5e53j322c50ff87ca5214@mail.gmail.com>

On Fri, Nov 21, 2008 at 12:15 PM, Addison Berry <drupal at rocktreesky.com>wrote:

>
> On Nov 20, 2008, at 7:40 PM, Joshua Brauer wrote:
> >>>
> >
> > In sort my vote would be that the email list should remain the
> > primary workspace and wiki pages, when appropriate, can serve a
> > valuable purpose as a supplement.
>
> Well the main problem is that we can't "occasionally" use wiki pages
> as a supplement. You have to be a member to use a wiki page and if we
> open up membership then folks can create any kind of group content
> which will end up spawning some discussions on g.d.o and some on the
> mail list.
>
>
I think it would be worth while to open up the group membership and see if
there is a natural migration towards them. In the same experimental mindset
as opening up the editing rights to everyone, lets try it out and see how it
goes. Yes, there may be problems with cross posting and etc, but lets see
what people gravitate towards and the evolutionary tendency.

I completely agree with Josh's assesment (especially about wiki competency)
and I am not a fan of deprecating the mailing list, but I'm willing to let
the masses speak and change my thinking. I would also point out that often
the reason for people's reluctance to joining a mailing list is the
perceived high traffic of them (which it usually isn't) and it would be
quite easy to setup the mailing lists to have a better archive interface by
joining services like mail-archive.org or nabble, so I don't think those are
solid reasons for deprecating the list.

One possibility would be to initially setup the group to only allow new
members to collaborate on wikis, so we can use it as a supplement (instead
of a full discussion forum).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081121/36817dc2/attachment.htm 

From drupal-docs at webchick.net  Fri Nov 21 02:28:30 2008
From: drupal-docs at webchick.net (Angela Byron)
Date: Thu, 20 Nov 2008 21:28:30 -0500
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
Message-ID: <FF253B32-D32A-4DC2-90B2-B1534CC23090@webchick.net>


On 20-Nov-08, at 7:40 PM, Joshua Brauer wrote:

> Comments below. I'm NOT a fan of the idea of deprecating the mailing  
> list for the reasons below.

While I was originally in favour of the move to g.d.o on the grounds  
that most people find web interfaces more friendly than e-mail, I  
actually found myself nodding along with basically all of Josh's points.

If the main idea is to have central rallying points for organizing  
stuff, then... why not do so right on Drupal.org?

For example, http://drupal.org/please-review-my-patch is a sort of "ad- 
hoc" page that members of the Drupal 7 core development team use to  
escalate issues up to me that are either "quickies" that could be  
committed while I'm on one of my many daily phone calls, or that  
really need core maintainer intervention because they are dead-locked  
in discussion or need architectural advice. And, unlike  
groups.drupal.org, drupal.org has no problem displaying the revision  
log: http://drupal.org/node/309321/revisions. And finally, it's really  
nice because you can do short-hand [#xxxxx] to automatically link to  
relevant issues.

Not sure if this will address the current needs of the docs team, but  
it's worth a thought?

But the bottom line is that g.d.o's current subscription and  
collaboration options are pretty lackluster compared to the power e- 
mail affords; until the situation improves, we are probably jumping  
ship too soon. The Documentation issue queue can be used for web-based  
conversations and comes complete with a very clear signal of whether  
an issue is dealt with or not, and handbook pages work better than  
g.d.o anyway for wiki-style collaboration.

-Angie


From drupal at rocktreesky.com  Fri Nov 21 03:02:31 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Thu, 20 Nov 2008 22:02:31 -0500
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <FF253B32-D32A-4DC2-90B2-B1534CC23090@webchick.net>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
	<FF253B32-D32A-4DC2-90B2-B1534CC23090@webchick.net>
Message-ID: <EA02EA17-9F38-4EF4-A549-9BD5B8C88392@rocktreesky.com>


On Nov 20, 2008, at 9:28 PM, Angela Byron wrote:

> If the main idea is to have central rallying points for organizing
> stuff, then... why not do so right on Drupal.org?
>
> For example, http://drupal.org/please-review-my-patch is a sort of  
> "ad-
> hoc" page that members of the Drupal 7 core development team use to
> escalate issues up to me that are either "quickies" that could be
> committed while I'm on one of my many daily phone calls, or that
> really need core maintainer intervention because they are dead-locked
> in discussion or need architectural advice. And, unlike
> groups.drupal.org, drupal.org has no problem displaying the revision
> log: http://drupal.org/node/309321/revisions. And finally, it's really
> nice because you can do short-hand [#xxxxx] to automatically link to
> relevant issues.
>
> Not sure if this will address the current needs of the docs team, but
> it's worth a thought?

Hm. Hm. Well, yeah it works in certain ways, but the main uses we have  
for wiki pages is for temporary stuff, like drafting up a forum post  
announcement to go to the front page or working out a new outline for  
a section of the handbook. How would we handle not cluttering up with  
lots and lots of these kind of pages that will never be used as real  
handbook pages? I guess we could just have a doc team book. That isn't  
as "stumble-upon-able" by casual contributors (which is one of my  
goals). Hm. The only other disadvantage would be that there is no  
email notification from handbook pages, but at least people could see  
them in their d.o tracker, which would be nice.

I still feel like that is harder for casual contributors to notice and  
get involved, but yeah, we could give that go in terms of at least  
being able to work together. Something to consider.




From shai at content2zero.com  Fri Nov 21 03:29:58 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Thu, 20 Nov 2008 22:29:58 -0500
Subject: [documentation] Proposal to deprecate the docs mailing list
In-Reply-To: <EA02EA17-9F38-4EF4-A549-9BD5B8C88392@rocktreesky.com>
References: <20081120233004.63A3C16B54E@www1.drupal.org>
	<CFA08F9D-209C-42F9-8860-3FE46C524307@rocktreesky.com>
	<36F2579F-0C2F-4327-8199-36BB947388A2@brauerranch.com>
	<FF253B32-D32A-4DC2-90B2-B1534CC23090@webchick.net>
	<EA02EA17-9F38-4EF4-A549-9BD5B8C88392@rocktreesky.com>
Message-ID: <9f68efb70811201929t7e879573k31efcfbf26d5e09d@mail.gmail.com>

This whole conversation is just screaming out to mobilize advocating for a
few basic improvements on g.d.o. I agree with Nat's suggestions for pushing
through full messages in notifications and installing mailhandler.

I agree that Wiki functionality on g.d.o without history and diff is
useless. I'd like to hear more details about what is holding this up? Is it
a problem specific to OG? It's pretty basic functionality.

*I think we should use whatever clout we have as an important group within
the Drupal community to get the needed changes to g.d.o. As Nat also said,
every other group is probably screaming for this also. Let's band together.*

What kind of example are we setting when tasks that clearly fall into the
realm of "Community Plumbing" are not being handled by Drupal?

Yes, e-mail has been the killer ap for a whole generation. It can be hard to
move away from it. But the future is server and not client. It's the
"Semantic Web" and not the junk heap on your (my) hard drive. We aren't
there yet, but I feel like it helps move everything forward when we are
willing to be guinea pigs in attempting to actually use the technology we
are developing.

It was interesting hearing Angie's story of how the D7 core folks use
drupal.org pages for a similar need. Clever! But I would call that a
"community plumbing hack." I don't want to start replicating hacks. I'd
rather try to get g.d.o fixed!

My 3 cents,

Shai

On Thu, Nov 20, 2008 at 10:02 PM, Addison Berry <drupal at rocktreesky.com>wrote:

>
> On Nov 20, 2008, at 9:28 PM, Angela Byron wrote:
>
> > If the main idea is to have central rallying points for organizing
> > stuff, then... why not do so right on Drupal.org?
> >
> > For example, http://drupal.org/please-review-my-patch is a sort of
> > "ad-
> > hoc" page that members of the Drupal 7 core development team use to
> > escalate issues up to me that are either "quickies" that could be
> > committed while I'm on one of my many daily phone calls, or that
> > really need core maintainer intervention because they are dead-locked
> > in discussion or need architectural advice. And, unlike
> > groups.drupal.org, drupal.org has no problem displaying the revision
> > log: http://drupal.org/node/309321/revisions. And finally, it's really
> > nice because you can do short-hand [#xxxxx] to automatically link to
> > relevant issues.
> >
> > Not sure if this will address the current needs of the docs team, but
> > it's worth a thought?
>
> Hm. Hm. Well, yeah it works in certain ways, but the main uses we have
> for wiki pages is for temporary stuff, like drafting up a forum post
> announcement to go to the front page or working out a new outline for
> a section of the handbook. How would we handle not cluttering up with
> lots and lots of these kind of pages that will never be used as real
> handbook pages? I guess we could just have a doc team book. That isn't
> as "stumble-upon-able" by casual contributors (which is one of my
> goals). Hm. The only other disadvantage would be that there is no
> email notification from handbook pages, but at least people could see
> them in their d.o tracker, which would be nice.
>
> I still feel like that is harder for casual contributors to notice and
> get involved, but yeah, we could give that go in terms of at least
> being able to work together. Something to consider.
>
>
>
> --
> 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/20081120/696b6c0b/attachment.htm 

From hans.drupal at gmail.com  Fri Nov 21 04:34:25 2008
From: hans.drupal at gmail.com (HansBKK)
Date: Fri, 21 Nov 2008 11:34:25 +0700
Subject: [documentation] Proposal to deprecate the docs mailing list
	(Hans Henderson)
Message-ID: <361c29f50811202034v54cabbc8k975580b9c8d2d858@mail.gmail.com>

Big +1 from me

Joshua makes some great technical points, but it comes down to
preference and work style, and mine is to visit a web location to
participate in a discussion rather than having it come to me.

I do think it shouldn't be that hard to get the best of both worlds
with some enhancements that would benefit all OG sites and Drupal in
general, but also recognize that Moshe's got limited bandwidth to
implement any code changes. But would be nice. . .

From webweaver64 at yahoo.com  Fri Nov 21 04:27:37 2008
From: webweaver64 at yahoo.com (Shari)
Date: Thu, 20 Nov 2008 22:27:37 -0600
Subject: [documentation] Problem With One of the Main CVS Pages
In-Reply-To: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
References: <9f68efb70811191459q5d531907r7dca9bd2dc887a1e@mail.gmail.com>
Message-ID: <492638B9.1060602@yahoo.com>

I thought I would add what someone who doesn't know anything about HEAD 
or CVS thought when going to the page...

Reading what is there, I would have assumed it was talking about the 
latest unstable release of version 6. Because I didn't know for sure 
what HEAD referred to I moved backward, along the breadcrumb, to "Drupal 
and CVS", I still wasn't sure if HEAD was referring to 6 or 7. So I 
clicked on CVS FAQ it isn't answered there but there is a note: "- 
What's "HEAD"? What should I use it for?" as something that needs to be 
answered. So then I went back, and clicked on "Drupal CVS branches and 
tags" to see if it was explained there. I found "The HEAD branch is 
special and is used to refer to the latest development version.," still 
doesn't answer if it's 6.7 or 7.x. There was a link for a more detailed 
explanation, which I clicked on and got this:

"In /Drupal core/, HEAD is the name given to the version of Drupal core 
being worked on by developers right now. Of course, now that core is 
only using two digits for the version number (starting with the 5.0 
release), there's no longer any ambiguity about what the next version of 
core will be called, so the use of "HEAD" to identify a release is no 
longer necessary. For example, now that the official 6.0 release of 
Drupal core is out, everyone knows that the next version of core under 
development will eventually become the 7.x release series, so the 
nightly snapshot releases are more properly called "7.x-dev", not "HEAD"."

The 1st part seems to be saying that it would be the next 2 digit core 
version which would mean it would be 6.7, but then it says it's 7.x-dev, 
so I'm still not sure what HEAD refers to. Is it 6.7 or 7.x?

Also the title, actually doesn't mean anything to me either. Checking 
out from the main repository, wouldn't be something I would have any 
idea of meaning, and would most likely ignore it. I would suggest 
Getting files from the main repository, Downloading from..., Access the ...

I thought I would share my entire process, so you can see why some of 
this does indeed need to be made clearer if the intention is for anyone 
visiting and wanting to learn, to be able to understand. I know, I don't 
know or understand some of the lingo, and am willing to move back, or 
attempt to find the information, however as in this case even trying to 
find the information left me still not understanding, and if I have to 
work harder then this, it's likely to be something I just let go.

Now that I just typed all that, I reread the original post, and noticed 
that Shai had placed stable release in italics, this leads me to believe 
that 7 is what you get when you dl HEAD. If HEAD is indeed 7, I would 
suggest something like this to explain it: Once a version has been 
released e.g. 6.0, all further version release under the number 6, are 
considered "Stable" releases and not "Development" releases. The HEAD or 
development release would be the next /full /number e.g. 7.x

Shari

Shai Gluskin wrote the following, On 11/19/2008 4:59 PM:
> Hi gang,
>
> This is about http://drupal.org/node/320
>
> The title of the page is: /Checking out from the main repository
>
> /The assumption on that page is that you want to check out HEAD. There 
> is one small section which says, "If you want to check out a specific 
> version of Drupal..."
>
> I believe the assumption of the page should be opposite, that you want 
> to check out a specific version of Drupal. That is how you can check 
> out the latest stable release.
>
> The use-case for checking out HEAD is for core committers or folks 
> testing patches to core. That is very important. However, I think the 
> vast majority of people wanting to get their feet wet in CVS (and 
> therefore coming to this handbook page) want to check out the latest 
> /stable release/ in order to make it easier to upgrade the next time 
> an updated stable release is deployed.
>
> I'd like to edit the page so that the primary instructions are for 
> checking out a specific version and the secondary instructions are for 
> folks wanting to checkout HEAD.
>
> I thought this was a big enough change that I wanted to run it by others.
>
> Thanks,
>
> Shai
> ------------------------------------------------------------------------
>
> --
> Pending work: http://drupal.org/project/issues/documentation/
> List archives: http://lists.drupal.org/pipermail/documentation/

From hans.drupal at gmail.com  Fri Nov 21 04:41:33 2008
From: hans.drupal at gmail.com (HansBKK)
Date: Fri, 21 Nov 2008 11:41:33 +0700
Subject: [documentation] Proposal to deprecate the docs mailing list
	(HansBKK)
Message-ID: <361c29f50811202041j15cc59afsb2f0de3604c80af7@mail.gmail.com>

Sorry to come back so quick but I just got the digest

Big -1 from me on keeping both - I'd rather keep things as they are
than do that.

Fewer places to check is critical, having different cliques in
different media sucks. It's hard enough to build consensus!

AFAIK **drop** them both; all conversations could take place in the
issues queue, IMO the bumping feature there is very helpful (ref's
Joshua's point on old conversations), and it's mail notifications are
I think? just as good as GDO.

On Fri, Nov 21, 2008 at 11:34 AM,  <documentation-request at drupal.org> wrote:
> Send documentation mailing list submissions to
>        documentation at drupal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.drupal.org/listinfo/documentation
> or, via email, send a message with subject or body 'help' to
>        documentation-request at drupal.org
>
> You can reach the person managing the list at
>        documentation-owner at drupal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of documentation digest..."
>
>
> Today's Topics:
>
>   1. Re: Proposal to deprecate the docs mailing list (Ryan Cross)
>   2. Re: Proposal to deprecate the docs mailing list (Angela Byron)
>   3. Re: Proposal to deprecate the docs mailing list (Addison Berry)
>   4. Re: Proposal to deprecate the docs mailing list (Shai Gluskin)
>   5. Re: Proposal to deprecate the docs mailing list   (Hans
>      Henderson) (HansBKK)
>   6. Re: Problem With One of the Main CVS Pages (Shari)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Nov 2008 12:58:40 +1100
> From: "Ryan Cross" <drupal at ryancross.com>
> Subject: Re: [documentation] Proposal to deprecate the docs mailing
>        list
> To: "A list for documentation writers" <documentation at drupal.org>
> Message-ID:
>        <4e983be00811201758r26cc5e53j322c50ff87ca5214 at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, Nov 21, 2008 at 12:15 PM, Addison Berry <drupal at rocktreesky.com>wrote:
>
>>
>> On Nov 20, 2008, at 7:40 PM, Joshua Brauer wrote:
>> >>>
>> >
>> > In sort my vote would be that the email list should remain the
>> > primary workspace and wiki pages, when appropriate, can serve a
>> > valuable purpose as a supplement.
>>
>> Well the main problem is that we can't "occasionally" use wiki pages
>> as a supplement. You have to be a member to use a wiki page and if we
>> open up membership then folks can create any kind of group content
>> which will end up spawning some discussions on g.d.o and some on the
>> mail list.
>>
>>
> I think it would be worth while to open up the group membership and see if
> there is a natural migration towards them. In the same experimental mindset
> as opening up the editing rights to everyone, lets try it out and see how it
> goes. Yes, there may be problems with cross posting and etc, but lets see
> what people gravitate towards and the evolutionary tendency.
>
> I completely agree with Josh's assesment (especially about wiki competency)
> and I am not a fan of deprecating the mailing list, but I'm willing to let
> the masses speak and change my thinking. I would also point out that often
> the reason for people's reluctance to joining a mailing list is the
> perceived high traffic of them (which it usually isn't) and it would be
> quite easy to setup the mailing lists to have a better archive interface by
> joining services like mail-archive.org or nabble, so I don't think those are
> solid reasons for deprecating the list.
>
> One possibility would be to initially setup the group to only allow new
> members to collaborate on wikis, so we can use it as a supplement (instead
> of a full discussion forum).
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.drupal.org/pipermail/documentation/attachments/20081121/36817dc2/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Nov 2008 21:28:30 -0500
> From: Angela Byron <drupal-docs at webchick.net>
> Subject: Re: [documentation] Proposal to deprecate the docs mailing
>        list
> To: A list for documentation writers <documentation at drupal.org>
> Message-ID: <FF253B32-D32A-4DC2-90B2-B1534CC23090 at webchick.net>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On 20-Nov-08, at 7:40 PM, Joshua Brauer wrote:
>
>> Comments below. I'm NOT a fan of the idea of deprecating the mailing
>> list for the reasons below.
>
> While I was originally in favour of the move to g.d.o on the grounds
> that most people find web interfaces more friendly than e-mail, I
> actually found myself nodding along with basically all of Josh's points.
>
> If the main idea is to have central rallying points for organizing
> stuff, then... why not do so right on Drupal.org?
>
> For example, http://drupal.org/please-review-my-patch is a sort of "ad-
> hoc" page that members of the Drupal 7 core development team use to
> escalate issues up to me that are either "quickies" that could be
> committed while I'm on one of my many daily phone calls, or that
> really need core maintainer intervention because they are dead-locked
> in discussion or need architectural advice. And, unlike
> groups.drupal.org, drupal.org has no problem displaying the revision
> log: http://drupal.org/node/309321/revisions. And finally, it's really
> nice because you can do short-hand [#xxxxx] to automatically link to
> relevant issues.
>
> Not sure if this will address the current needs of the docs team, but
> it's worth a thought?
>
> But the bottom line is that g.d.o's current subscription and
> collaboration options are pretty lackluster compared to the power e-
> mail affords; until the situation improves, we are probably jumping
> ship too soon. The Documentation issue queue can be used for web-based
> conversations and comes complete with a very clear signal of whether
> an issue is dealt with or not, and handbook pages work better than
> g.d.o anyway for wiki-style collaboration.
>
> -Angie
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 20 Nov 2008 22:02:31 -0500
> From: Addison Berry <drupal at rocktreesky.com>
> Subject: Re: [documentation] Proposal to deprecate the docs mailing
>        list
> To: A list for documentation writers <documentation at drupal.org>
> Message-ID: <EA02EA17-9F38-4EF4-A549-9BD5B8C88392 at rocktreesky.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Nov 20, 2008, at 9:28 PM, Angela Byron wrote:
>
>> If the main idea is to have central rallying points for organizing
>> stuff, then... why not do so right on Drupal.org?
>>
>> For example, http://drupal.org/please-review-my-patch is a sort of
>> "ad-
>> hoc" page that members of the Drupal 7 core development team use to
>> escalate issues up to me that are either "quickies" that could be
>> committed while I'm on one of my many daily phone calls, or that
>> really need core maintainer intervention because they are dead-locked
>> in discussion or need architectural advice. And, unlike
>> groups.drupal.org, drupal.org has no problem displaying the revision
>> log: http://drupal.org/node/309321/revisions. And finally, it's really
>> nice because you can do short-hand [#xxxxx] to automatically link to
>> relevant issues.
>>
>> Not sure if this will address the current needs of the docs team, but
>> it's worth a thought?
>
> Hm. Hm. Well, yeah it works in certain ways, but the main uses we have
> for wiki pages is for temporary stuff, like drafting up a forum post
> announcement to go to the front page or working out a new outline for
> a section of the handbook. How would we handle not cluttering up with
> lots and lots of these kind of pages that will never be used as real
> handbook pages? I guess we could just have a doc team book. That isn't
> as "stumble-upon-able" by casual contributors (which is one of my
> goals). Hm. The only other disadvantage would be that there is no
> email notification from handbook pages, but at least people could see
> them in their d.o tracker, which would be nice.
>
> I still feel like that is harder for casual contributors to notice and
> get involved, but yeah, we could give that go in terms of at least
> being able to work together. Something to consider.
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 20 Nov 2008 22:29:58 -0500
> From: "Shai Gluskin" <shai at content2zero.com>
> Subject: Re: [documentation] Proposal to deprecate the docs mailing
>        list
> To: "A list for documentation writers" <documentation at drupal.org>
> Message-ID:
>        <9f68efb70811201929t7e879573k31efcfbf26d5e09d at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> This whole conversation is just screaming out to mobilize advocating for a
> few basic improvements on g.d.o. I agree with Nat's suggestions for pushing
> through full messages in notifications and installing mailhandler.
>
> I agree that Wiki functionality on g.d.o without history and diff is
> useless. I'd like to hear more details about what is holding this up? Is it
> a problem specific to OG? It's pretty basic functionality.
>
> *I think we should use whatever clout we have as an important group within
> the Drupal community to get the needed changes to g.d.o. As Nat also said,
> every other group is probably screaming for this also. Let's band together.*
>
> What kind of example are we setting when tasks that clearly fall into the
> realm of "Community Plumbing" are not being handled by Drupal?
>
> Yes, e-mail has been the killer ap for a whole generation. It can be hard to
> move away from it. But the future is server and not client. It's the
> "Semantic Web" and not the junk heap on your (my) hard drive. We aren't
> there yet, but I feel like it helps move everything forward when we are
> willing to be guinea pigs in attempting to actually use the technology we
> are developing.
>
> It was interesting hearing Angie's story of how the D7 core folks use
> drupal.org pages for a similar need. Clever! But I would call that a
> "community plumbing hack." I don't want to start replicating hacks. I'd
> rather try to get g.d.o fixed!
>
> My 3 cents,
>
> Shai
>
> On Thu, Nov 20, 2008 at 10:02 PM, Addison Berry <drupal at rocktreesky.com>wrote:
>
>>
>> On Nov 20, 2008, at 9:28 PM, Angela Byron wrote:
>>
>> > If the main idea is to have central rallying points for organizing
>> > stuff, then... why not do so right on Drupal.org?
>> >
>> > For example, http://drupal.org/please-review-my-patch is a sort of
>> > "ad-
>> > hoc" page that members of the Drupal 7 core development team use to
>> > escalate issues up to me that are either "quickies" that could be
>> > committed while I'm on one of my many daily phone calls, or that
>> > really need core maintainer intervention because they are dead-locked
>> > in discussion or need architectural advice. And, unlike
>> > groups.drupal.org, drupal.org has no problem displaying the revision
>> > log: http://drupal.org/node/309321/revisions. And finally, it's really
>> > nice because you can do short-hand [#xxxxx] to automatically link to
>> > relevant issues.
>> >
>> > Not sure if this will address the current needs of the docs team, but
>> > it's worth a thought?
>>
>> Hm. Hm. Well, yeah it works in certain ways, but the main uses we have
>> for wiki pages is for temporary stuff, like drafting up a forum post
>> announcement to go to the front page or working out a new outline for
>> a section of the handbook. How would we handle not cluttering up with
>> lots and lots of these kind of pages that will never be used as real
>> handbook pages? I guess we could just have a doc team book. That isn't
>> as "stumble-upon-able" by casual contributors (which is one of my
>> goals). Hm. The only other disadvantage would be that there is no
>> email notification from handbook pages, but at least people could see
>> them in their d.o tracker, which would be nice.
>>
>> I still feel like that is harder for casual contributors to notice and
>> get involved, but yeah, we could give that go in terms of at least
>> being able to work together. Something to consider.
>>
>>
>>
>> --
>> 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/20081120/696b6c0b/attachment-0001.htm
>
> ------------------------------
>
> Message: 5
> Date: Fri, 21 Nov 2008 11:34:25 +0700
> From: HansBKK <hans.drupal at gmail.com>
> Subject: Re: [documentation] Proposal to deprecate the docs mailing
>        list    (Hans Henderson)
> To: documentation at drupal.org
> Message-ID:
>        <361c29f50811202034v54cabbc8k975580b9c8d2d858 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Big +1 from me
>
> Joshua makes some great technical points, but it comes down to
> preference and work style, and mine is to visit a web location to
> participate in a discussion rather than having it come to me.
>
> I do think it shouldn't be that hard to get the best of both worlds
> with some enhancements that would benefit all OG sites and Drupal in
> general, but also recognize that Moshe's got limited bandwidth to
> implement any code changes. But would be nice. . .
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 20 Nov 2008 22:27:37 -0600
> From: Shari <webweaver64 at yahoo.com>
> Subject: Re: [documentation] Problem With One of the Main CVS Pages
> To: A list for documentation writers <documentation at drupal.org>
> Message-ID: <492638B9.1060602 at yahoo.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I thought I would add what someone who doesn't know anything about HEAD
> or CVS thought when going to the page...
>
> Reading what is there, I would have assumed it was talking about the
> latest unstable release of version 6. Because I didn't know for sure
> what HEAD referred to I moved backward, along the breadcrumb, to "Drupal
> and CVS", I still wasn't sure if HEAD was referring to 6 or 7. So I
> clicked on CVS FAQ it isn't answered there but there is a note: "-
> What's "HEAD"? What should I use it for?" as something that needs to be
> answered. So then I went back, and clicked on "Drupal CVS branches and
> tags" to see if it was explained there. I found "The HEAD branch is
> special and is used to refer to the latest development version.," still
> doesn't answer if it's 6.7 or 7.x. There was a link for a more detailed
> explanation, which I clicked on and got this:
>
> "In /Drupal core/, HEAD is the name given to the version of Drupal core
> being worked on by developers right now. Of course, now that core is
> only using two digits for the version number (starting with the 5.0
> release), there's no longer any ambiguity about what the next version of
> core will be called, so the use of "HEAD" to identify a release is no
> longer necessary. For example, now that the official 6.0 release of
> Drupal core is out, everyone knows that the next version of core under
> development will eventually become the 7.x release series, so the
> nightly snapshot releases are more properly called "7.x-dev", not "HEAD"."
>
> The 1st part seems to be saying that it would be the next 2 digit core
> version which would mean it would be 6.7, but then it says it's 7.x-dev,
> so I'm still not sure what HEAD refers to. Is it 6.7 or 7.x?
>
> Also the title, actually doesn't mean anything to me either. Checking
> out from the main repository, wouldn't be something I would have any
> idea of meaning, and would most likely ignore it. I would suggest
> Getting files from the main repository, Downloading from..., Access the ...
>
> I thought I would share my entire process, so you can see why some of
> this does indeed need to be made clearer if the intention is for anyone
> visiting and wanting to learn, to be able to understand. I know, I don't
> know or understand some of the lingo, and am willing to move back, or
> attempt to find the information, however as in this case even trying to
> find the information left me still not understanding, and if I have to
> work harder then this, it's likely to be something I just let go.
>
> Now that I just typed all that, I reread the original post, and noticed
> that Shai had placed stable release in italics, this leads me to believe
> that 7 is what you get when you dl HEAD. If HEAD is indeed 7, I would
> suggest something like this to explain it: Once a version has been
> released e.g. 6.0, all further version release under the number 6, are
> considered "Stable" releases and not "Development" releases. The HEAD or
> development release would be the next /full /number e.g. 7.x
>
> Shari
>
> Shai Gluskin wrote the following, On 11/19/2008 4:59 PM:
>> Hi gang,
>>
>> This is about http://drupal.org/node/320
>>
>> The title of the page is: /Checking out from the main repository
>>
>> /The assumption on that page is that you want to check out HEAD. There
>> is one small section which says, "If you want to check out a specific
>> version of Drupal..."
>>
>> I believe the assumption of the page should be opposite, that you want
>> to check out a specific version of Drupal. That is how you can check
>> out the latest stable release.
>>
>> The use-case for checking out HEAD is for core committers or folks
>> testing patches to core. That is very important. However, I think the
>> vast majority of people wanting to get their feet wet in CVS (and
>> therefore coming to this handbook page) want to check out the latest
>> /stable release/ in order to make it easier to upgrade the next time
>> an updated stable release is deployed.
>>
>> I'd like to edit the page so that the primary instructions are for
>> checking out a specific version and the secondary instructions are for
>> folks wanting to checkout HEAD.
>>
>> I thought this was a big enough change that I wanted to run it by others.
>>
>> Thanks,
>>
>> Shai
>> ------------------------------------------------------------------------
>>
>> --
>> Pending work: http://drupal.org/project/issues/documentation/
>> List archives: http://lists.drupal.org/pipermail/documentation/
>
>
> ------------------------------
>
> _______________________________________________
> documentation mailing list
> documentation at drupal.org
> http://lists.drupal.org/listinfo/documentation
>
>
> End of documentation Digest, Vol 48, Issue 7
> ********************************************
>

From shai at content2zero.com  Fri Nov 21 05:07:00 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Fri, 21 Nov 2008 00:07:00 -0500
Subject: [documentation] Proposal to deprecate the docs mailing list
	(HansBKK)
In-Reply-To: <361c29f50811202041j15cc59afsb2f0de3604c80af7@mail.gmail.com>
References: <361c29f50811202041j15cc59afsb2f0de3604c80af7@mail.gmail.com>
Message-ID: <9f68efb70811202107n54e26b71h7dfecad65820f557@mail.gmail.com>

Hans and Documenters,

The notifications in the queue are *better* than g.d.o. in my opinion. But I
still vote for g.d.o. + advocating for improvements at g.d.o.

The problems I have with using the queue for docs group processing are:

   1. The queue's appropriate focus is task/response, not designed for
   discussion. When there is a discussion in the queue, half the time someone
   will interrupt you and say, "that's a duplicate" -- or "start a new issue."
   I like those people. They impose order in a zone where people are trying to
   get things done. It's not for open discussion
   2. It takes newbies a while to learn the queue
   3. I think the pics/avatar possibility on g.d.o is really important.
   Seeing people's faces, or even their avatar's reminds me to think more of
   the other people involved, and not just the back-and-forth of words.

[p.s. -- the first time I tried posting it got rejected "waiting moderation"
because it was more than 40K. This was do just to the quoting, requoting...
one of the disasters of e-mail, though at least gmail has made that better
on the UI side - but not on the back end. One more reason to go web-based!]

Shai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081121/59c93bb9/attachment.htm 

From hans.drupal at gmail.com  Fri Nov 21 06:25:44 2008
From: hans.drupal at gmail.com (HansBKK)
Date: Fri, 21 Nov 2008 13:25:44 +0700
Subject: [documentation] Draft for d.o. front page announcement
Message-ID: <361c29f50811202225o377ad1e0qf5ab95981dd254b9@mail.gmail.com>

As per Addi's request in the recent IRC meeting, here is an initial
draft for a general "The Theming Handbook is being reorganized!"
announcement for the d.o. community, possibly to be promoted to the
front page.

http://drupal.org/node/337208

From hans.drupal at gmail.com  Fri Nov 21 06:34:27 2008
From: hans.drupal at gmail.com (HansBKK)
Date: Fri, 21 Nov 2008 13:34:27 +0700
Subject: [documentation] Proposal to deprecate the docs mailing list
	(HansBKK)
In-Reply-To: <361c29f50811202041j15cc59afsb2f0de3604c80af7@mail.gmail.com>
References: <361c29f50811202041j15cc59afsb2f0de3604c80af7@mail.gmail.com>
Message-ID: <361c29f50811202234j6d8f39aeuc793047b1a8acaad@mail.gmail.com>

Is it possible for specific nodes in the Group to be individually "wikified"?

If so, I'm now inclined to say make the choice:

1 leave things as they are

2 deprecate mailing list without generally opening up the Group

In the interest of not splintering discussion further - the issue
queue already gives us a central "forum" for posting questions and
having back and forth, with a IMO better feature set than OG.

I personally think this functionality is largely duplicated with the
mail list, which I don't use much and don't see much activity on these
days anyway, so either of the above choices would work for me.

We have IRC for real-time meetings and quick ad-hoc side discussions.

I say leave the Group as generally read-only to highlight current
projects and major announcements. When we want to get feedback from
the larger d.o. community, this is the place for a post with open
comments as we've been doing.

The only thing missing is a wiki-like space outside the Handbooks
themselves for collaborative editing. Personally I think that GDO
isn't a good place for that either, but can't think of a better one.

As a related note, please visit http://drupal.org/node/337121 if you
are interested in checking out real-time collaborative editing tools.

From hans.drupal at gmail.com  Fri Nov 21 06:48:12 2008
From: hans.drupal at gmail.com (HansBKK)
Date: Fri, 21 Nov 2008 13:48:12 +0700
Subject: [documentation] documentation Digest, Vol 48, Issue 7
In-Reply-To: <mailman.16043.1227249270.9743.documentation@drupal.org>
References: <mailman.16043.1227249270.9743.documentation@drupal.org>
Message-ID: <361c29f50811202248y6adec525o3a790b5d025faf1c@mail.gmail.com>

Shai and docs team,

I recognize that the queue wasn't designed for discussion, but I do
think it in fact works well for that (as you agree).

I think the culture of that medium being task-focused (as you point
out), is helpful for those of us that tend to waffle on, especially
when we do get pointed to past-but-still-active parallel threads we
may not have seen.

And I don't think the waffling gets in the way (too much?) for those
more focused on getting specific tasks done - the recent/unread posts
do float to the top, and once we've seen a topic no longer of interest
to it we mentally screen it out just as we would in a forum.

The fact that the queue works better than GDO (now does) as a
discussion forum means (to me): don't convert the group to (another)
discussion forum.

From catch56 at googlemail.com  Fri Nov 21 12:15:49 2008
From: catch56 at googlemail.com (Nathaniel Catchpole)
Date: Fri, 21 Nov 2008 12:15:49 +0000
Subject: [documentation] Documentation pages in the redesign
Message-ID: <fa5724270811210415n367776c2le1eebc88d00a13ed@mail.gmail.com>

Mark Boulton Design posted the 9th iteration of the Drupal.org redesign
yesterday and it's had a lot of updates in terms of documentation, so
pinging this list with it:

Iteration index: http://drupal.markboultondesign.com/iteration9/

Direct links to the documentation pages:

http://drupal.markboultondesign.com/iteration9/documentation.html
http://drupal.markboultondesign.com/iteration9/documentation_api.html
http://drupal.markboultondesign.com/iteration9/documentation_index.html
http://drupal.markboultondesign.com/iteration9/documentation_article.html

Announcement is here - http://groups.drupal.org/node/16950 and feedback
should be left there 'cos I'm sure they don't read this list. This is
probably the most important stage to be giving feedback on the iterations,
because as far as I know there's only one or two more left to go.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081121/fc4c61f6/attachment.htm 

From shai at content2zero.com  Fri Nov 21 15:59:09 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Fri, 21 Nov 2008 10:59:09 -0500
Subject: [documentation] documentation Digest, Vol 48, Issue 7
In-Reply-To: <361c29f50811202248y6adec525o3a790b5d025faf1c@mail.gmail.com>
References: <mailman.16043.1227249270.9743.documentation@drupal.org>
	<361c29f50811202248y6adec525o3a790b5d025faf1c@mail.gmail.com>
Message-ID: <9f68efb70811210759t6ac9db66ncba7ac3323981c2b@mail.gmail.com>

Hans and docs team,

Maybe we need to bring Moshe into the discussion: If the following were on
the horizon any time soon for g.d.o, I think it's the best venue for our
work:

   1. history and diff for wiki nodes
   2. full text in notification emails
   3. mailhandler installation

If these things are pie-in-the-sky, then I'd vote for using the queue as the
main gathering place.

Either way I'm still in favor of deprecating the mailing list.

Hans makes good points about the queue. I criticized the queue for being too
task focused and not good for discussion. But I agree with Hans that being
overly focused is better than having too little focus.

Regarding the needs of those who prefer email: while there is *some* chance
that g.d.o. might add Mailhandler, I think there is *no* chance that d.o.
would. So while notifications are better on d.o. there wouldn't be hope that
people could add comments or start topics via email.

[p.s. as more proof against list serves, note how Hans inadvertantly changed
the subject title in responding to this thread -- thus messing with even the
best of threading algorithms. Of course, Hans probably did that on purpose
since he's in favor of deprecating the list serve :)]

Shai



Shai
I don't see a page in the Handbook describing the Documentation Team.
On Fri, Nov 21, 2008 at 1:48 AM, HansBKK <hans.drupal at gmail.com> wrote:

> Shai and docs team,
>
> I recognize that the queue wasn't designed for discussion, but I do
> think it in fact works well for that (as you agree).
>
> I think the culture of that medium being task-focused (as you point
> out), is helpful for those of us that tend to waffle on, especially
> when we do get pointed to past-but-still-active parallel threads we
> may not have seen.
>
> And I don't think the waffling gets in the way (too much?) for those
> more focused on getting specific tasks done - the recent/unread posts
> do float to the top, and once we've seen a topic no longer of interest
> to it we mentally screen it out just as we would in a forum.
>
> The fact that the queue works better than GDO (now does) as a
> discussion forum means (to me): don't convert the group to (another)
> discussion forum.
> --
> 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/20081121/5ba83863/attachment.htm 

From drupal at rocktreesky.com  Fri Nov 21 16:03:46 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Fri, 21 Nov 2008 11:03:46 -0500
Subject: [documentation] Nov. 20 IRC meeting Summary and Log
References: <20081121155016.3C7BB16B54E@www1.drupal.org>
Message-ID: <A7F2FC8C-82AD-4D49-B132-91765BA8A453@rocktreesky.com>


> add1sun has posted a Discussion at http://groups.drupal.org/node/16977
>
> Nov. 20 IRC meeting Summary and Log
> ---------------
> Once again, big thanks to Hans for pulling together a summary for  
> us. The original IRC log is here: http://pastebin.com/f13c30b7a
> Announcements
==============
>
> - Leisa from MBD has a new post up re: docs redesign ideas: http://www.disambiguity.com/drupalorg-redesign-a-strategy-for-the-documentation-section/
> - The next iteration (#9) of the redesign just went up http://drupal.markboultondesign.com/iteration9/
> - The FP post re: open editing is up
> - We are testing out using an online colab tool called Diigo to see  
> if this helps us hammer on issues directly in the handbook pages.  
> Read more about that here: http://drupal.org/node/332021
>
> Agenda
========
>
> **New page holding pen: http://lists.drupal.org/pipermail/documentation/2008-November/006351.html
> Basically we've got +1s on this so I'd like to implement it. There  
> is an issue for drupal.org customizations since this will take a  
> patch code to implement.
> **New projects on radar:
>
> ******Getting started guide for D6 needs basic content completed
> We need to get the content filled out and we can start by copying  
> stuff from the D5 guide and then updating to D6. Shai_ stepped up to  
> commit time to this. The question was raised on why we are creation  
> a "duplicate" version rather than trying to generalize like we are  
> with themeing. Basically the idea that it is simply faster to do  
> that right now, while the need is rather urgent, and there is a  
> correlation between the D5 HTML and PDF. (Note by Addi, while I  
> proposed and argued this, I'm not totally convinced that duplication  
> is a good idea. I'd like to talk out a plan a little more this  
> weekend, if possible.)

> ******Reorganizing the theme guides
> Main issue: http://groups.drupal.org/node/16594
> HansBKK has taken the lead on a theme guide team to get the theme  
> guides somewhat sane and will be the main point of contact for  
> questions. Theme team to post recommendations via issues to the main  
> queue for feedback before making major changes. They will give a  
> status report every couple of weeks. Addi will do the top-level book  
> wrangling first and then the team can take over.
> HansBKK has written up a "Heads-up: we're rearranging again"  
> announcement draft to the issue queue for feedback, Addi will  
> promote to front page.
>
> The team will try using Diigo, a "social bookmarking" tool:
> - browser extension or bookmarklet + website, drupal-docs team has  
> its own group
> - allows for tagging and sticky notes to be posted directly to the  
> pages under discussion. no copy/paste back and forth
> - "meta" discussion re page classification and navigation hierarchy  
> can take place there without cluttering up the main doc team's  
> channels
>
> All docs team members invited to join:
> - sign up with Diigo first: http://www.diigo.com
> - then come to the drupal-docs group here: http://groups.diigo.com/groups/drupal_docs 
>  and request
> - then go to the head of the D6 theming guide and try it out, add  
> sticky notes to pages, highlight text then add a sticky to the  
> highlight.
>
> Diigo guidelines:
> - only post d.o. links to the drupal-docs group, and for now limited  
> to theming stuff
> - use Diigo's discussion facilities just for "meta" issues re page  
> classification and navigation hierarchy
> - substantive content discussion to take place in main docs-team  
> channels on d.o.
>
> Current members on Diigo:
> Heather - (nearlythere)
> Addi (add1sun)
> Richard (siliconmeadow)
> Hans (hansbkk)
> Lee (leehunter)
> Wolf (wolfflow)
> Shai (shaigluskin)
> dvessel

>
> ******Reviewing/expanding the handbook style guide and creation of  
> some basic templates
> siliconmeadow and LeeHunter stepped up to help guide this one.
> We determined that there really is no need for a separate writer's  
> guide and style guide. One place that says "this is how we do stuff  
> here" would probably be more useful. So we need to look at  
> consolidating the current pages:
> http://drupal.org/documentation-writers-guide
> http://drupal.org/about/authoring
> Would also be nice if we can work on adding some sample templates  
> for project help files (like INSTALL.txt and README.txt)

>
> ******Additional topic that came up was using groups.drupal.org and  
> deprecating the mail list
> The discussion on this was brief and positive enough to post for  
> more talk. There is a g.d.o post and a mailing list post.

From hans.drupal at gmail.com  Sat Nov 22 16:08:24 2008
From: hans.drupal at gmail.com (HansBKK)
Date: Sat, 22 Nov 2008 23:08:24 +0700
Subject: [documentation] No more version-specific books! (GS?)
Message-ID: <361c29f50811220808q31495185qc4d5e2b1886bb5eb@mail.gmail.com>

Please have a look at my (admittedly somewhat desperate-sounding) post
to the issues queue: http://drupal.org/node/337079

And post your feedback here or there as you prefer.

The project page is here:  http://drupal.org/node/337079

but comments aren't turned on

From shai at content2zero.com  Sun Nov 23 21:48:23 2008
From: shai at content2zero.com (Shai Gluskin)
Date: Sun, 23 Nov 2008 16:48:23 -0500
Subject: [documentation] Ordering of Major Admin Sections in Getting Started
	Guide
Message-ID: <9f68efb70811231348i18e9ce51tef5c0a3b12551204@mail.gmail.com>

Hi Folks,

Obviously when discussing D6 administration, the major sections of Drupal's
administration screen will be the organizing principle in presenting the
material.

Right now the order those sections are discussed on the handbook page are
different from the order in the book menu. I will make sure that will be
consistent.

But this raises another question. What should the order of those major admin
sections be?

The order I like best is the one that the Drupal Administration Menu
Module<http://drupal.org/project/admin_menu>uses. Since core never
lays them out sequentially, but rather in columns
that you can read down or across, I thought it would be reasonable to use
admin_menu's order. And it is a hugely popular module, so it would reinforce
something that people are likely to see when they get around to installing
that module.

Here is the order:

   1. Content management
   2. Site building
   3. Site configuration
   4. User Management
   5. Reports


Anybody have a disagreement with this order?

If anyone wants to help out on the D6 Getting Started Guide, let me know. I
know Heather is working on it. I'm just trying to provide a little guidance.

Thanks,

Shai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20081123/09f911e1/attachment-0001.htm 

From hans.drupal at gmail.com  Mon Nov 24 00:53:29 2008
From: hans.drupal at gmail.com (HansBKK)
Date: Mon, 24 Nov 2008 07:53:29 +0700
Subject: [documentation] Ordering of Major Admin Sections in Getting
	Started Guide
Message-ID: <361c29f50811231653kb32c26cy1580041ed7cd09af@mail.gmail.com>

Ordering - looks good to me Shai.

I really like Admin menu myself.

Re the subject header, I have to change it manually because I'm on digest.

From drupal at ryancross.com  Mon Nov 24 03:13:42 2008
From: drupal at ryancross.com (Ryan Cross)
Date: Mon, 24 Nov 2008 14:13:42 +1100
Subject: [documentation] Ordering of Major Admin Sections in Getting
	Started Guide
In-Reply-To: <361c29f50811231653kb32c26cy1580041ed7cd09af@mail.gmail.com>
References: <361c29f50811231653kb32c26cy1580041ed7cd09af@mail.gmail.com>
Message-ID: <4e983be00811231913k180af3d8j8a7b3a03ac133e3e@mail.gmail.com>

I am not sure which I would prefer, but I think there could be a strong
argument made for ordering the sections based on the initial actions/desires
of the new users. Similar to the steps laid out in a fresh install. Namely:

1) Site configuration (setting site name, etc)
2) Site building (adding modules, themes)
3) Content Management (adding a node)
4) User Management (deciding who can do what with that content)
5) Reports (is everythign working right?)
6) Help (shouldn't be forgotten, and could arguably go at the top for
documentation purposes and get people more familiar with using the help
system)

#3 and #4 could potentially be swapped, but that's the way the current
introduction to the system is done I think.

-Ryan

On Mon, Nov 24, 2008 at 11:53 AM, HansBKK <hans.drupal at gmail.com> wrote:

> Ordering - looks good to me Shai.
>
> I really like Admin menu myself.
>
> Re the subject header, I have to change it manually because I'm on digest.
> --
> 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/20081124/d77a2c51/attachment.htm 

From john at noceda.net  Mon Nov 24 02:37:11 2008
From: john at noceda.net (John Noceda)
Date: Mon, 24 Nov 2008 03:37:11 +0100
Subject: [documentation] Ordering of Major Admin Sections in Getting
 Started Guide
In-Reply-To: <9f68efb70811231348i18e9ce51tef5c0a3b12551204@mail.gmail.com>
References: <9f68efb70811231348i18e9ce51tef5c0a3b12551204@mail.gmail.com>
Message-ID: <492A1357.6080301@noceda.net>

Hi!

Shai Gluskin wrote:
> The order I like best is the one that the Drupal Administration Menu 
> Module <http://drupal.org/project/admin_menu> uses. Since core never 
> lays them out sequentially, but rather in columns that you can read 
> down or across, I thought it would be reasonable to use admin_menu's 
> order. And it is a hugely popular module, so it would reinforce 
> something that people are likely to see when they get around to 
> installing that module.
>
> Here is the order:
>
>    1. Content management
>    2. Site building
>    3. Site configuration
>    4. User Management
>    5. Reports
>
I think that core does lay them out sequentially at  
*/admin/build/menu-customize/navigation page. This is the same order in 
the Drupal Administration Menu Module 
<http://drupal.org/project/admin_menu> so I reckon that it's the default 
sequential order.  I am using suckerfish on my sites' primary links so 
the first thing I do is move the "administer" link from the Navigation 
menu to primary links menu and it is the same order as you have stated.

> Anybody have a disagreement with this order?
I think this is very good for consistency. :-)

John
JohnNoc (drupal.org/groups.drupal.org/drupalnorge.no/etc.)
_JohnNoc_ (irc)


From drupal at rocktreesky.com  Mon Nov 24 13:34:47 2008
From: drupal at rocktreesky.com (Addison Berry)
Date: Mon, 24 Nov 2008 08:34:47 -0500
Subject: [documentation] Holiday travel
Message-ID: <9B23D6F3-D509-47C1-8AD3-AE6DCFE32A3C@rocktreesky.com>

There are a number of important discussions going on right now  
regarding documentation (e.g. theming guide, versioning docs, mail  
list/g.d.o) so I want to give everyone a heads-up that I will be  
traveling for vacation this week, for the U.S. Thanksgiving holiday. I  
will have internet access to check in, but most likely very little  
time to respond to the extended discussions. I just wanted to let  
everyone know that I'm not ignoring the issues, just a bit out of  
commission for this week. I'll be back next Sunday, Nov. 30.

- Addi (add1sun)
--------------------------------------
Join us at Do It With Drupal!
A large scale, curated education event
December 10-12, New Orleans
http://www.doitwithdrupal.com