Discussion

Here is a proof of concept I was trying out this morning.
I wanted to read the SimpleTest documentation on my (non-internet connected) ereader so I made an ePub document out of the all the web pages. This centralizes the content into an (almost real) book that can be read on most electronic readers (with working Table Of Contents, embedded images, etc).

Due to the file upload restrictions (it doesn't recognize the '.epub' extension), you must change the '.html' to '.epub' after you download it, in order to read it.

Hey all -

DrupalCon Chicago's Core Conversation proposals need to be in by next Friday. Jennifer (jhodgdon) and I have been pondering whether and what might make a good topic or two to pitch.

Please post with ideas and whether you'd be interested in attending a docs focused session, it'll help us gear our proposal towards something everyone will be interested in!

Thanks!

Hi, All --

Awhile back I suggested a DITA "mash-up" structure and workflow process that I thought might be a candidate for the Drupal docs--this was based on my prior work as a DITA consultant, my reading of the Drupal doc group discussions, and my own understanding of what I assume are typical problems putting together an open-source, structured/unstructured collection of topics.

My business partner and I have put together a model DITAmashup collection on one of our sites that is accompanied by a post explaining how we did it and what we think are its benefits:

After a big discussion with some of the core devs who attended the PNW Drupal Summit last weekend, I've created a page for people who don't consider themselves part of the Docs Team to sign up as willing to mentor people working on Docs. http://drupal.org/node/936522

The idea is that people working on docs often need help with technical details of what they're documenting, and don't know who they can ask. The people I was talking to were more than willing to help out, and we also talked about pairing up docs people with contrib maintainers so they can help maintain project-specific docs.

At dinner tonight Add1sun and I chewed over the question:

Why does Drupal's contrib maintenance model largely work, and handbook maintenance does not work?

While Drupal's contrib area is certainly not perfect, it has active maintenance on many projects, and a clear sense of ownership, and rules that go with that ownership. Everybody can contribute in the issue queue, and everybody can comment in the issue queue. But the maintainers are responsible for the their project.

A ping in #drupal-docs earlier has brought to my attention that the Docs style guide only applies to handbook and not explicitly to interface text in Drupal core/contrib.

I'd think it should apply so we get consistent text and grammar formatting Drupal-wide, but didn't want to make such a sweeping declaration without some consensus from the community at large.

I'm about to tackle a modest project in the Accessibility pages and just wanted to be sure I wasn't reproducing anyone else's work. Anyone here working on those docs? (Our Accessibility group actually is coordinating a project to improve that content. I am plugged in with [the rest of] them.) If so, please touch base with me so we can collaborate.

With a quick run-through of the program, I didn't see any talks of BoFs related to documentation on the CPH site.

I'm very interested in starting to help out with Drupal documentation, and I know there will be a need for a big push with D7. I'm just not sure where to start. I was hoping to meet up with some people in Copenhagen to give me a quick primer and sketch out some of the areas most in need of work.