[documentation] New handbook section proposal: "Community Initiatives"

John Noceda john at noceda.net
Thu Jan 22 03:00:15 UTC 2009


Creating a top-level book does not mean that it has to become a handbook. So
my suggestion is, even if we're utilizing the book content type, we do not
call this a handbook and not list it on http://drupal.org/handbooks. We
instead make a link on the "Contributor Links" block called "Community
Initiatives" right after the "Advanced Search" and before the "Queue". Then
it becomes a project management tool related to the issues queue and not
related to documentation. The documentation blocks: "Quick Links" and
"Handbook License" shouldn't be visible on this top-level book. We then
announce the new functionality on the front page. The documentation
admins/managers (or whatever name we decide on this on another on-going
discussion) will then make it a task to explain the "Community Inititiative"
feature in the "Getting Involved" handbook.

IMHO, this put things in proper places. Listing it under the "Contributor
Links" block makes it more visible to the correct target audience as well as
it gives the impression of a better connection with the issues queue. My
point is that it's a project management tool and not documentation.


John


-----Original Message-----
From: documentation-bounces at drupal.org
[mailto:documentation-bounces at drupal.org] On Behalf Of Gábor Hojtsy
Sent: 21. januar 2009 17:39
To: A list for documentation writers
Subject: Re: [documentation] New handbook section proposal: "Community
Initiatives"

On Wed, Jan 21, 2009 at 5:28 PM, Addison Berry <drupal at rocktreesky.com>
wrote:
>> It almost sounds like this should be a view rather than just books 
>> hierarchy, since it could include time-frame-limited things, etc.
>> Maybe it is a "dashboard" of embedded views of 2 or 3 different kinds 
>> things? It just seems like something requiring more relational 
>> connections rather than hierarchical burying.
>
> Yeah, I agree that figuring views into this would be nice and I still 
> think that we need to take a real look at an "ideal" long-term 
> solution. We also need to find a short-term solution that does *not* 
> involve views though. We do not have Views enabled on d.o and it will 
> not be until after the upgrade/redesign stuff, but Angie is in need of 
> some sort of overarching way to organize things *now* and this seemed 
> the handiest way to go. I did also raise the fact that we now have 
> tags and wouldn't using the taxo lists for tags be one way to go, but 
> Angie didn't like it because she wants to highlight only the 
> "important" stuff.

We got to same / similar conclusions with the redesign / upgrade project
planning. We can tag stuff, but in huge projects, such as these, we need a
hierarchic, prioritized plan for what should happen.
Therefore I've extended the drupal.org project filter, so if you use
[#112233] (with the issue number), you'll get the status and the assigned
user to the output already. From here, we can use this to build nested lists
with annotations, images, etc for bigger project plans. This is all due to
our project module lacking things like milestones, relative priority,
project plans, etc, and they will not be implemented anytime soon (not that
they should be). Flat views listing is not cutting it, since you cannot
order stuff by relative priority (eg. an issue might be an important thing
for implementing the map on the redesigned homepage, but the map on the
redesigned homepage is not the highest priority overall). Tags don't provide
a way for people to understand the process of implementing a big change in
Drupal or on drupal.org, the order of them, cross-dependencies, etc.

What we do because of the lack of higher project planning tools, milestones,
etc. is a bit hackish, but looks like we prefer to use drupal.org then to
use a third party, where these would be available, since here we can utilize
our userbase, issue status data, etc, which we already have.

Gábor
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/



More information about the documentation mailing list