• Where (which site?)
  • Info
  • Doc
    • Basic docs exception
  • Dev
    • Developers Mailing List
  • Profiles
  • Themes
  • Community (tiki.org)
    • Translations & i18n
• What not to do
• Related pages
• Undecided
  • Still anything relevant on old doc motion?
  • Pages about a technology or a standard
  • Documentation about making themes
  • Release notes and What is new in each release
  • Discussions about themes
  • About improving a site.
    • Pro
    • Against
  • Demonstrating a bug
  • Should demo go from community to info
    • Pro
  • News
    • info
    • community
• Footer
• Where (type of data)
  • Wiki
  • Forum post/Mailing list
  • Blog post & news article
  • Bug tracker
  • Comments
  • Events & Calendar
  • Private email & chat
  • Group chat

https://info.tiki.org

 Note

Please note the info.tiki.org is a redirect to a perspective view of the tiki.org site now and is the default you see when you access https://tiki.org directly.

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?

Provide an outlet for the "official" voice of Tiki and the Tiki Software Community Association.

• News about Tiki (releases, patches, security, etc)
• Information about Tiki community
• Events (both TikiFests and other events that have a Tiki presence) in calendar format.

• Tiki Admins
• Tiki Software Community Association members
• Communications Team

https://doc.tiki.org
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".

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.

Maybe there should be a few perspectives to split this?

https://dev.tiki.org
Improving Tiki

Perhaps this one should be split into more than one perspectives

1. What to improve
   • Feature requests (including brainstorming)
   • Bug reports
2. How to develop in Tiki (maybe this should be on tiki.org?)
   • Procedures & documentation for developers
   • "How can I improve Tiki code?"
3. Translations
   • How to improve translation process
   • Work on actual translations
4. Security
   • Everything related to Security

(aka tikiwiki-devel AT lists.sourceforge.net)
Improving Tiki, Dev announcement, semi-live brainstorming, Commit process discussion
Devs and active members of the Tiki Community use this list to:

• Communicate "Dev" events ( Roundtable-Meetings, TikiFest, Release process, etc )
• Commit guideline questions
• Invitation to test specific changes or additions
• Adding features, options, defaults or changes that require brainstorming and/or consensus in the community

• Feature requests and bug reports should be made on http://dev.tiki.org and not be made via the the dev mailing list, as they can get lost, and they create noise for community members that don't use that feature. If you feel it's important to share on tiki-devel, it's OK to send a single short message about it with a link to the bug report and asking that follow-up discussions happen on the bug report.
  • Brainstorming before reporting a bug (ex.: "I am not sure this is a bug or I just don't understand the feature") is acceptable, but sneaky use of this will be pointed out.
• Issues with the infrastructure (ex.: one site is down) should be made on http://dev.tiki.org (pick the category "dogfood on a *.tiki.org site)

https://profiles.tiki.org
How to configure Tiki
Out of the box solutions

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

https://themes.tiki.org
Keywords: Front-end, CSS, templates, icons, fonts

What Tiki looks like
Download and participate to look & feel related (How does it look?)
Eveything related to mobile, because it's an alternate theme/view on the content

For developers

https://tiki.org/community

• Support requests (forums) (if/when confirmed as a bug, they go to dev)
  • If support requests becomes too vague to be handled through the forum. If per exemple the help required must come from a super user. Then the group or person asking for support should create a link to the requirement.
    • Exemple 1: How does a user send a blog post to a list of email addresses he wishes to force registration
    • Exemple 2: How can a community member convince a Host Provider to use Tiki
• Events
  ricks99 thinks that the "official" Tiki calendar of events should be on info.tw.o It should include:
  • TikiFest
  • Other events that have a Tiki presence (e.g., someone from the community giving a presentation about/using Tiki)
    • The official calendar is on info, but each event will have a wiki page on the community site?
• 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.: tiki.org/enterprise is better than profiles.tiki.org/enterprise What we need is Sister Wiki

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?

https://translation.tiki.org

Should collaboration about translations be on dev or on tw.o? On one hand, it is about improving Tiki code. On the other hand, it's very easy code and it relates to community things (local events, etc.). Perhaps the best is that everything related to translation be a workspace of tiki.org to make it easier for translators. So let's make it that way: dev.tiki.org should assume you only will work in English.

From the moment you are working on a non-English site, all the info should be in a workspace of tiki.org or a wish in the i18n category (because we want feature requests and bugs to be centralized).

The i18n workspace should cater to the following

• I am a translator and I want to improve Tiki interface translations (system messages)
• I want to use Tiki in multilingual mode (to manage my own content)
• I am a developer who wants to improve Tiki the application
• I want to participate to the Tiki community in my own language (ex.: forums, local events)

Maybe we should have i18n.tiki.org for the translation perspective, and give the translation server another name?

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 is 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 should be a FAQ in wiki pages.
4. Do not document other projects like here: http://doc.tiki.org/Install+Turk+MMCache (now removed) It's better to help the other project on their site, and simply link to it.

   
   

• Top10
• WhoWhat
• SisterWiki
• Domains

  
  

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

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

On doc? http://doc.tiki.org/Themes or on http://themes.tiki.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...

• 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.

This being said, if there is a link from Tiki to the doc site, they should be a short page, describing the feature in 1 sentence with a link to the relevant page on themes.tiki.org

doc.tiki.org/Themes should be a gateway page with everything related to themes. A long series of short sentences and links.

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.

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).

TwoRevamp, DevTwoRevamp, DevTwoDogFood and Admin tasks should be on tiki.org because it's about community organization and planning.

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

• That page is not about improving Tiki, the application

Sometimes, it's useful to have a page, etc. to demonstrate a bug. http://demo.tiki.org is a good place for this

Or even better, the show.t.o instances linked to bug reports.

Try Tiki

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

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

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

This will be a common footer for the main *.tiki.org domains. See http://branding.tiki.org/Footer+code.

Tiki has several features and tiki.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?

• 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

  
  

http://en.wikipedia.org/wiki/NPOV

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

• 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:

• Forum_and_List_Sync

• 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)

• 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 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.

• 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.

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

• 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).
• See: Chat

• Where to post
• Where to participate
• Where to add content