[drupal-docs] establishing a process/workflow for creating,
submitting, editing documentation
Charlie Lowe
cel4145 at cyberdash.com
Fri May 20 15:18:43 UTC 2005
Boris Mann wrote:
>
> I'd vote for using project issues, just to raise the level of
> quality. I can imagine things getting drowned out/confusing in the
> forums.
So far you are the only vote. Anyone else have one feeling one way or
the other?
>
> The RSS was key for me personally. I could see what was happening,
> and go and review the docs I was interested in.
>
>
>>One way I could imagine would be some kind of notification for book
>>maintainers so that they know when changes have been made. Boris has
>>suggested the subscriptions module. I think even the notify module
>>could
>>work.
>
>
> Actually, my long subscriptions module rant was about centralizing
> subscriptions and having them manage both RSS feed items (i.e.
> everyone has their own subscriptions/feed, just like the buddylist
> feed) and email notification. Out of scope/needs development for now,
> but the essential issue of external notification remains (Dries: the
> updates page doesn't do external notification, so it's not
> particularly useful).
>
> I think, with the proper level of notification, we could turn off
> moderation for book pages...i.e. make it completely wiki like. There
> are enough eyes/people with permission to be able to roll back to the
> previous revision.
>
> My short term wish for notification technology is:
> * add RSS to the tracker
> * add per-node-type tracking (e.g. tracker/book and tracker/book/feed)
>
> If we don't want to make changes to core, then I would build around
> the commentrss module (or something).
>
> I'd be willing to post a bounty to help get this built.
Definitely some good ideas in there for the doc team responsible for
technology initiatives to think about. Should we put you down on the doc
team as someone who would like to participate?
More information about the drupal-docs
mailing list