On 10/6/2010 05:56, Clayton wrote:
On 10/06/2010 10:54 AM, TJ Frazier wrote:
As for the wiki, I suggest that we need a version-marking system, with a
bug on the page. If we make that show in the edit summaries, then users
can easily access whatever version they want :-) Nothing is lost on the
wiki.
We have that in a way... I tinkered a little with it today, but for
whatever reason (I haven't figured out why just yet) it's not working
quite right.
We have an extension called FlaggedRevs available. it's currently
disabled by default, but it can be enabled wiki-wide, or on specific
pages. My preference is to enable it across the wiki, but some people
grumbled about it... so for now we can enable ti on a per-page basis.
http://wiki.services.openoffice.org/wiki/Help:Page_validation
I tested it on one page, and although i could enable the flaggedrevs for
this page, I couldn't seem to trigger the validation part... so all I
ended up with was an icon/text top right of the page stating it was an
unreviewed page.
I temporarily enabled the extension across the whole wiki and tried
again... same result.
So... anyone have any experience with flaggedrevs? Maybe we could find a
way to get this working. then we can enable this on pages/books we want
to flag as static, set it it so any edits are not shown, but are in a
moderation queue...
Unless someone has another idea of course :-)
C.
The problem with FlaggedRevs is that it is designed for /quality/
control, not /version/ control; I'm afraid it's not suitable for our
purposes.
May I suggest a script that does the following:
The main routine takes a Guide name as a parameter, and calls a
subroutine which:
1) Takes as input a page name (like,
[[Documentation/OOo3_User_Guides/Writer_Guide]])
2) Adds this name to a table, excluding duplicates (exits, or proceeds
conditionally)
3) Finds the TOC call on that page (warns if none found)
4) For each page in the body of the TOC call, calls itself recursively.
When the table is completely built, for each entry, the main routine
calls a subroutine which:
5) examines each table page for existing version marker; deletes if found.
6) adds to each table page a version marker (icon or text) up near the
top, like "<!--Version Marker-->(V3.3)", with an edit summary like,
"updated to V3.3 (bot)".
(Notes: more efficient algorithms are possible, but do the expected
volume and frequency justify such? I think we want to be sure that the
table is completely and correctly built before we do any editing.)
The script would be run at the beginning of updating a given Guide. It's
probably okay that the version would be wrong until the actual updating,
but if somebody wants to be fancy, a first run of the script could add,
"updating to" and a second run replaces that with the version; this is
just a change in the marker and summary content.
In theory, if all versions were so marked, we could even print a book
for any given version. In practice, a user should be able to find the
older version in the History tab for any particular page. We may want a
Help entry on how to do this, and a reference to that on the Doc page.
--
/tj/
---------------------------------------------------------------------
To unsubscribe, e-mail: authors-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: authors-h...@documentation.openoffice.org
