History: Where
Preview of version: 71
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.
Please also see
http://branding.tiki.org/Top+Menu
Table of contents
- Where (which site?)
- What not to do
- Related pages
- Undecided
- Footer
- Where (type of data)
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".
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.
All edits should be watched by:
- Tiki Admins
- Tiki Software Community Association members
- Communications team
Pages that should move there (with a redirect): Reviews, Nice Sites, Why Use Tiki and any other similar page.
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.
Maybe there should be a few perspectives to split this?
Dev
Improving Tiki
Perhaps this one should be split into two perspectives
- What to improve
- Feature requests (including brainstorming)
- Bug reports
- How to develop in Tiki
- Procedures & documentation for developers
- "How can I improve Tiki code?"
- Security
- Everything related to Security
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 (tiki.org)
- 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
- 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.
- 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
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?
Translations & i18n
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)
Currently, there is a translation server at i18n.tiki.org should contains no "permanent" info because we give admin access to all translators and we could wipe the site every once in a while.
Maybe we should have i18n.tiki.org for the translation perspective, and give the translation server another name?
What not to do
Here are examples of what not to do, and why.
- 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.
- Do not put support requests in a wiki page. Use forums instead.
- Examples of difficult to manage pages:
- Error Messages should be a FAQ in wiki pages.
- Do not document other projects like here: http://doc.tiki.org/Install+Turk+MMCache It's better to help the other project on their site, and simply link to it.
Related pages
Undecided
Still anything relevant on old doc motion?
http://doc.tiki.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.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...
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.
Marc:
I think the underlying guideline should be to focus on making things better for theme designers. Theme designers should have a dedicated space just for them. They don't want to be cluttered with feature information (doc) or with programming info (dev). They just want to know how to make it look like they want it to. So I think everything related to making a theme or modifying a theme should be on themes.tiki.org (including discussions, tips, etc). The only thing that should be in doc is the very basic stuff (how to pick a theme, how to use Site Identity). Themes, very much like the profile site could be split in three section: Use, Create (including modify), Develop (which means discussions/info about how to change Tiki to be better for theme designers).
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.
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).
About improving a site.
TwoRevamp, DevTwoRevamp, DevTwoDogFood and Admin tasks should be on tiki.org because it's about community organization and planning.
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. http://demo.tiki.org is a good place for this
Should demo go from community to info
Pro
Community is for people that are already decided to use Tiki. Demo is more for marketing.
News
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 *.tiki.org domains. See http://branding.tiki.org/Footer+code.
Where (type of data)
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?
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).