Tiki is a large project, application and community

This page is help answer the questions

• Where do I find stuff?
• Where do I participate?

Goal:

• Avoid content duplication and increase opportunity for merging/refactoring
• Increase confidence that if a certain content is not where it should be, it just doesn't exist yet.

Where (which site?)

Info

Introduction, clean gateway to various Tiki sites and pages.
Think Marketing, this site must not be unfocused

• What is Tiki?
• Is Tiki a good choice for me?

The site is targeted for people that have not yet picked TiKi for their project. In the commercial World, this would be "Pre-Sales questions".

Doc

What Tiki does

• Documentation about Tiki, the application
• Tutorials how to use Tiki
• Doc is not concerned about community organization, philosophy, open source, etc. It's documentation about Tiki as a "product".

Document specific features. How to combine features to address a use case is in Profiles

Basic docs exception

Tiki documentation about backup is not a Tiki feature, but since it's basic info, it should be on doc as well, along with Install, upgrade, but not Troubleshooting, Toolbox, etc.

Dev

What Tiki should do

• Feature requests (including brainstorming)
• Bug reports
• Procedures & documentation for developers
• "How can I improve Tiki code?"

For developers

Profiles

How to configure Tiki
Out of the box solutions

• Solutions by combining features
• Tutorials how to configure Tiki
• Default settings, etc.

For power users

Themes

What Tiki looks like
Download and participate to look & feel related (How does it look?)

For developers

Community (tikiwiki.org)

• Support requests (forums) (if/when confirmed as a bug, they go to dev)
• Events
• Community projects and coordination to improve the community, including all the various Team pages.
• User Pages (please keep personal stuff there)
• When Tiki4 rolls out, we'll start using Workspaces with Organic Groups
• All the rest that doesn't fit in info/dev/doc/profiles/themes
• Gateway pages that explain something we want to promote. Ex.: tikiwiki.org/enterprise is better than profiles.tikiwiki.org/enterprise What we need is Sister Wiki

But please don't use for tests, there is demo for that.

There is overlap and many shades of grey on where things should go. Beyond which site to put in on, there is also should this go in a wiki page, a forum/mailing list post, a comment, etc?

How to address the fact that many posts are not in the right forum?

What not to do

Here are examples of what not to do, and why.

1. Do not put bug reports in the documentation (doc is for what Tiki does, not a wishlist). It's ok to report the bug on dev and to link to it from doc. A problem is that this stuff is never removed. So it's better in the forum, where it clear how old it is and who wrote it.
2. Do not put support requests in a wiki page. Use forums instead.
3. Examples of difficult to manage pages:
   • Error Messages
   • Installation Problems

Related pages

• Top10
• WhoWhat
• SisterWiki
• Domains

Undecided

Still anything relevant on old doc motion?

http://doc.tikiwiki.org/Editorial+Board+Meeting+2007+08#Clarify_roles_of_TikiWiki_sites_PASSED_

Pages about a technology or a standard

For example, Ajax, Mootools, jQuery, MicroFormats, etc...

Documentation about making themes

On doc? http://doc.tikiwiki.org/Themes or on http://themes.tikiwiki.org/ ?

Xavi:

• I think that every page of documentation should be findable at doc.tw.o. I mean, searching for something related to Tiki in a single search box in doc.tw.o, should retrieve the information about it. Maybe some trick made by Rick might be useful for that.
• Besides that, if documentation of themes (o workflow, or profiles, etc.) is outside doc.tw.o, I think that doc.tw.o should have some page at the right place in the Documentation with an IFRAME insertion of that documentation. Somebody browsing the Documentation Structure should be able to read the documentation about side things (themes, profiles, etc.). Otherwise, new users get lost about having documentation in so many sites for general stuff (themes, profiles, etc.). DOcumentation for mods is another issue...

Gary (chibaguy):

• My thinking was that doc.tw.o would have the documentation on Tiki out of the box, like the owner's manual of a product - how to install it, set it up, and use its standard features. In my opinion, doc.tw.o doesn't need to cover topics that aren't part of the default package, such as modifications of Tiki, or third-party things such as mods and themes. Although it's possible for doc.tw.o to cover those topics, I think there is also a danger of information overload (the site is already heavy with info and needs to cover multiple releases, etc.). So making a logical separation of information on themes seems good to me, especially if the separation is clearly described at the front of each site.
• If navigation and sheer load are not problems at doc.tw.o, then information on themes could be both there and at themes.tw.o. But I do think the first choice for information on theme-making and availability of themes logically is themes.tw.o. (I think it would be great if the INCLUDE plugin could grab a page from the other site to include, so the content could be maintained at one site but viewed (and found in searches) at another. A problem with iframes is that the source page is that of another site and won't turn up in a search.

Release notes and What is new in each release

on Community or Doc? or maybe even info?

Xavi:

• wherever, and IFRAME'd in the other site, if you wish. Release notes: in tw.o, I would say. "What's new" for devs: in dev.tw.o or in tw.o. "What's new for end users" (like Tiki2, Tiki3, ...), in doc.tw.o.

Discussions about themes

In community forums or themes site? or here Why Tiki themes never look WOW ?

Xavi: if themes.tw.o has to exists (a part from tw.o), then I would suggest to keep discussion about themes in themes.tw.o , and the forum about themes in tw.o close it and leave apost informing everyybody to post about themes at the other site.

Gary (chibaguy): I'd prefer theme-related posts to be a themes.tw.o, but as long as tw.o still has a "themes" forum, people will post in it, naturally. Maybe the themes forum at tw.o should be made read-only, with a note and link to post at themes.tw.o instead, if that's our choice.
I'd like themes info to have more visibility at tw.o, like a thumbnail of a random new theme in a module, linked to the site, or more visibility for all the other project sites (new links at page top are a good step).

Translations

Should collaboration about translations be on dev or on tw.o?

About improving a site.

TwoRevamp should be on the community site. But what about DevTwoRevamp, DevTwoDogFood and Admin tasks

Pro

• It's visible to people that are affected (backlinks, etc)

Against

• That page is not about improving Tiki, the application

Demonstrating a bug

Sometimes, it's useful to have a page, etc. to demonstrate a bug.

Should demo go from community to info

demo

Pro

Community is for people that are already decided to use Tiki. Demo is more for marketing.

News

• Merge news on info & community (and have rewrite rules and not loose hit stats)

info

More official, easier to maintain quality and avoid clutter.

community

Easier to get comments about news
It's typically community-related stuff

Footer

This will be a common footer for the main *.tikiwiki.org domains.

Where (type of data)

Tiki has several features and tikiwiki.org uses many of these. How to know what should go in a wiki page? a forum post?

If you just have one tool, it is possible to use wiki pages for discussions (ex.: Talk Pages), and forums for permanent content (Sticky posts). However, when you have many tools at your disposal, which one should you choose?

Ask yourself the following questions:

• Do you think this information will be relevant far in the future? (ex.: in 2 years)
• Will this content evolve?
• Does it have a status? (open, solved, etc.)
• Is this a collective work? or a dialogue/discussion?
• One shot or recurring?
• Is it useful that we have a trace that this was discussed? (Or we just put it out, fix/do it and never deal with it again.
• Or is this a never ending thing?

Wiki

• Page evolves, but current version is supposed to always have best info.
  • History is interesting to track what changes as it evolves. But people that are new to a page rarely care to know about the evolution. The important is the current state.
• Building knowledge
• A project or procedure (in effect or proposed)
• Recently modified pages are usually highlighted (Recent Changes)
• Typically not important who the authors are

Wiki pages are typically not for opinions. If they are, it should be a place to indicate various points of view. Think
http://en.wikipedia.org/wiki/NPOV

Your own wiki page is a great place to express your opinion. Forums too!

Forum post/Mailing list

• Forums with good push are like mailing lists and mailing lists with good archiving are like forums. Too sides of the same coin.
• Newer content is at the top (in the web archive or in inbox)
• Great for:
  • I don't know what I don't know.
  • Has anyone ever done X?
  • Can Tiki do Y?
  • Support request: "May I have help to understand/configure a feature?" I am not saying there is a bug in the application. That may be the case, but I need more information/help to make that determination.
  • I have a project, I want to get initial feedback before I take the time to make a Wiki page with a more formal proposal.
  • I did make a wiki page with a project or procedure and here is the link:

Blog post & news article

• Newer content is at the top
• Old news can be interesting to consult but it's not updated. At best, there is an erratum, and/or links to related news (which can be more recent)
• Articles are more official "press release style" company news, while blogs are more a team or person status report (can be more informal)

Bug tracker

• Higher rated information is at the top. Things are supposed to be acted upon.
• Many ways to filter the information (assigned to, category, priority, etc.)

Comments

• Comments are useful to add content/opinions to a wiki page, tracker, etc but it's very clear who wrote what when and that it's "unofficial" content. Comments can become desynchronized and irrelevant to current wiki page content.

Events & Calendar

• Reading last 10 news articles can still be interesting. But if you missed an event, it's not much use to have the info. You want to always see next 10 events.

Private email & chat

• Not worth polluting the wiki with short lived or private info.

Group chat

• Very similar to Forum post/Mailing list, expect only people that are online can react. So can be fine for quick feedback, but for more vast consensus, a forum/mailing list is better (with possible link to a wiki page).