Loading...
 
Skip to main content

Editorial Board Meeting November 2007

This is a page for the meetings every month of the Editorial Board - Each month moti0ons passed or rejected are moved to a month specific Editorial board page (see below). Undecided motions are carried over to the next month. Passing a motion requires 50% plus one of the current members. Members who miss two consecutive meetings are no longer considered current.


See backlinks to go to EB meeting October 07 to read more about this proposal... (Xavi)


kerrnel22: I'd like to table a couple of items for discussion...

Items for discussion by kerrnel22

Do we want to settle on a single common language for screenshot examples on doc.tw.o, or allow any language the author happens to be using?

- More for consistency than anything, is there any policy or practice that is used for documentation language as a baseline? By and large, most folks accept that documentation will be written in english first for most things since that appears to be a common denominator. The great thing about Tiki is that there is built-in language translations - unfortunately that does not apply to screenshots. I was looking at the documentation for a feature called Contribution, which seems pretty cool. I could read the english version of the page, but the screenshots were in what I guess is Spanish since xavi appears to have written the page (and the feature?). I don't understand a lick of Spanish, so it's hampering me from understanding the examples completely. My question is do we want to settle on a single common language for screenshot examples on doc.tw.o, or allow any language the author happens to be using? (xavi, would love to hear more about this feature...I might be able to use it at work)


Discussion: I've previously tagged some non english screenshots as needing updates. I'm also grateful for any help we get with docs. dthacker

Proposal for documentation page formatting...

This really stems from 1.9 vs. 1.10. I would like to propose an "Information" sub-section on each doc page relating to features/mods/etc which would contain sub-headings with related information like:


Import forums

Blurb about what the feature does.

Change Log

Outlines significant changes in the appearance or behaviour of the feature...

1.9.8.3 - Introduced.
1.10.0 - Added ability to import directly from another DB server.
1.10.1 - Able to now migrate phpBB3 forums.
1.11.0 - Removed SQL dump import option because seldom used.
Known Issues

1.9.8.3 - Only works with mysql for sql dump import.

Examples

blahblahblah....

Discussion:

  • You could make that "Starting Now we do it this way", but resources for feature archeology are usually not available. dthacker


Opposed: dthacker


Identify with a caption the version of Tiki each screenshot is from, with the goal of the screenshots matching either the current release, or the current release candidate, whichever is more imminent

Motion: - Last proposal, is to somehow tag or identify with a caption the version of Tiki each screenshot is from, with the goal of the screenshots matching either the current release, or the current release candidate, whichever is more imminent.

In the case of today, we would try and get all screenshots current as of 1.10.0 until we come up with a 1.10.1 down the road. The Change Log proposed above will fill in the blanks. Maybe also have a "-HEAD" version of the page that talks about and documents changes to an existing feature that are in development in the head branch. When the time comes, those details can be easily incorporated into the current release page. Obviously, if the feature doesn't exist yet, then instead of ahving a -HEAD version (for example Contributions-HEAD), then it'll just be the name of the feature (Contributions) and in the Change Log section we'd have "1.11.0 - Introduced". I think we need to document new features that are being developed, but keep it separate from what is current so as to avoid confusion.

  • All screenshots should have a standard caption including version. We could add an "under development" tag as the equivalent to HEAD.(dthacker)


In Favor: dthacker

Ok, the windbag is empty. Would love your thoughts on these. They are all meant to make it easier for users to identify what feature goes with what version of Tiki. Ideally each Feature would have its own 1.9.7, 1.9.8, 1.10.0 versions, but I think that'd be a ton of work, and besides which we've got page histories folks can view for the older version they want as long as the changes are beig documented in the comments.


Xavi: Yes, Kerrnel22, screenshots should be in the same language as the text.

  • In my case, by the time I wrote Contribution documentation, I just had time to add some screenshots in Catalan, the onoes I already had for my own documentation. Later on I made some more in English, by Wikisym2007 time... I have to find some time to fetch them, and replace the old ones from Contribution page.
  • it would be nice if there was the change to link screenshots in several languages of the same feature, etc. So that you can upload them all together of the same set in different languages, and they could be shown in the language of the user, if the image is available.

Documentation page formatting

Motion: Use for documentation page formatting something like the example shown here

Proposal for documentation page formatting... This really stems from 1.9 vs. 1.10. I would like to propose an "Information" sub-section on each doc page relating to features/mods/etc which would contain sub-headings with related information like:

ricks99: Here was my proposal for redesigning doc pages from a while ago. I'm not 100% pleased with it, but I think it does a good job making it easy to find the key information for a given feature (i.e., which Tiki version, required permissions, etc.).

Xavi: as a General Idea, I like it, ricks99. But I'm scared of the work of reformating that part of every single page.... Moreover, shouldn't we use somehow the tracker info here in doc.tw.o that Marc Laporte created and many have been updating for all features?

  • Which tracker are you talking about? Are you suggesting using trackers in place of wiki pages for features? How would that work? (ricks99)
  • We could make that "Starting Now we do it this way", but resources for feature archeology are usually not available. ricks99, I really like that feature summary, especially the permissions part. (dthacker)



In favour:

Opposed:

Clarify who is active on current EB Meeting

Motion: Include in each Editorial Board Meeting a clear statement of who is considered active each month, so that everybody gets clear idea of what has been successfully passed and what not.


In favour: Xavi, dthacker (who thinks he is still active)