SWOT Analysis for 2014 Spring

Strengths

New themes will be available for Tiki13+ when Bootstrap revamp is finished.

Wizards since Tiki12 help new admins to get started more easily.

Monthly webinar meetings have been useful

Release cycle is working

Release process and documentation are improved on each release

Release team is stable

Roles are getting more and more flexible (knowledge is spread)

Weaknesses

Things we are doing not so well

Release coordination is always stressful

It is the time when we feel how few people we are

Bug and regression fixing is painful

Documentation

doc.t.o (online)

Books (printed, ebooks). We need them updated to LTS version.

Helping new users to find online what they need

Information overload/hard to find on all tiki.org sites

Keeping critical servers with just one sysadmin (high bus factor, and low resilience)

Setting up servers in a way that other admins can not help with when we need it.

Opportunities

Promote using the new setup wizards (Profiles Wizard, Admin Wizard) to have most new Tikis set up easily without needing an expert with them.

Set up some infrastructure similar to "dev.t.o + show.t.o" to offer new site admins a free tiki hosting limited in time (12 months?).

One per t.o user account?

Set up server infraestructure with LTS Debian-based operating systems, so that other tiki admins willing to help can do so to reduce Bus factor and increase resilience of our community infrastructure.

Set up some server infraestructure (like the new server for nextdev.t.o & nextdoc.t.o) with TikiSuite to dogfood it?

host mother.tiki.org in the same virtual server where r.t.o is hosted (Ubuntu 12.04 LTS based, with ISPConfig). Delegated management can be done for some tasks, etc (includes ssh jailroot where needed).

Updating books to 12.x LTS:

Xavi is helping Rick to get the "Tiki essentials" updated to 12.x. Hopefully the internet site will be updated around the end of August 2014. The printed version, maybe before the end of the year? (probably after Tiki 14.0 will be released)

Suggestion : Perhaps Rick can in future work more closely with Xavi and devs to update his book on future version of Tiki, e.g. Tiki 15? That way the book can come out the same time the version be released, rather than months/years after it.

Threats

Loosing sites and organizations because too complicated to learn how to set up a site without human guidance from an expert

Too complicated to get a test site hosted and working for potential new site admins

Diverging too much from de-facto standards in some communities:

"Markdown" syntax being used in github, wordpress, moodle, ...

loosing basic important features for new site admins such as syntax highlighting (there were issues in 2013-2014 with codemirror to have it on by default)

not enough people using wysiwyg or anonymous edits, and thus, bugs that produce content to be lost were detected late are still unfixed.

Sysadmins are quite allergic to others messing with their systems and the good ones out of respect never do that until explicitly asked. Nevertheless login should be possible for multiple people on a standard server to reduce the bus factor and they should be either "gifted to automagically understand how things are set up", or there should be some documentation written somewhere accessible to them in order to help them understand how that specific server is set up (which might be different from other sysadmin recipes, as valid as the other one).

"Use standard procedures where possible, if there is no good reason to proceed differently"

Some day, another admin might have to enter your setup to help, and the more standard setup, the easier for them to get comfortable patching the system

Standard procedures is more a concept than a documented reality. Let's just use some guidelines by saying that standard is what is provided by the distro or packaged tools and non standard is what is overly clever. Keep It Simple and Silly because the next person needing to touch it might do so in a crisis in the middle of the night not awake yet.

"Document your setup, specially the non-standard procedures"

Every sysadmin has its own recipe on how to improve this or that section of the server, which deviates from the more standard procedure documented in other places. Document your changes, so that this important knowledge is not lost (in case of the unfortunate event that a bus "visits" you or something else happens), and in case of need, another person can easily find out your changes, and how to proceed there.

"Respect the environment set up by another admin"
This rule implies that more than one admin will have access to login to each server, to reduce our bus factor and increase the resilience of our Community.

"Don't mess with anything"

There should be backups (that should be documented also, as suggested in the previous rules), but it's way much better if we don't have to deal with retrieving and restoring backups, which usually involves some unexpected surprises or some content lost due to uncontrolled factors, etc.

"Fetch data only"

The safest way to enter a server that was set up by another admin is to fetch data only, to place it somewhere else, and play/fine tune it there to split services, clone servers, etc.

"Discuss changes in advanced where possible, and report back when urgent changes where needed"

If there was a very good reason to change something (e.g., patch a system after an important vulnerability has been reported and the main sys admin is unavailable for too long), discuss with others admins when possible before doing the change. And report back about your changes as soon as possible to that other admin, or other admins, when you had to apply them urgently for some important reason.

This way the community can stay responsive, if anything bad happens, fetch sites from the server and set them up on a new one managed by someone else. These concepts are being succesfully used by several admins in some servers (amette/Nelson, Xavi/Ferran/Alex, Xavi/Alex, Xavi/Carlos, ...; Though not extensively tested, amette didn't yet find a bus he liked enough to jump in front of it , but xavi had a road accident that took him off for many months and the servers set up this way evolved organically where needed and users of services didn't notice it .

1.1.2.5.2. O.S. and whether Control Panels

We seem to be moving nextdev/nextdoc/etc and mother.t.o to a new virtual server, and this task has been requested to be done by amette.

In order to have other people help in the administration of that new server (to prevent the one-man setups that are not resillient by design), I suggest that we can talk about the operating system and type of setup in that server. For instance, I know that a few of us are more used to debian-based servers and desktops (ubuntu, or others) than to Gentoo or other distributions (I remember amette was keen on setting up servers with Gentoo in the past). And some of us are already getting used to set up virtual servers with ISPConfig (Luci, Marc, me, and probably others), which allows also setting up ssh jailroots when needed, without compromising the security of the whole server, etc. And we have been documenting the procedure, so that others can read, share, improve, ...

Shouldn't we be able to talk about which is the best design of the new servers from the point of view of creating resilient systems?

This way, it shouldn't be so difficult that others can help in the administration, upgrading php when needed, etc., imho. (we will have the added value of the experience of doing sys admin work in similar servers already).

Marc traditionally took care of this but admins all have access to the domain control panel.

1.1.2.6. Releases

Marc traditionally went around looking for volunteers

Recent release managers include Jonny, Bernard, Nelson

Admins with enough training to perform a release:

Changi, Jonny, Nelson.

Admins Learning:

Luci, Xavi, Jyhem.

1.1.2.7. Lead Developer

LP tends to lead development of new features, usu funded by projects by various parties, e.g. Synergiq Solutions (Nelson's company), Marc, Geoff, Bernard, etc...

Jonny tends to be very active in many areas and in more maintenance stuff. Sometimes he is paid by all of various parties above (if related to customer projects), at other times it is volunteer work (esp around release time).

Who is the main development coordinator though? Someone who coordinates Releases, Security, Themes, Profiles and also Testing by various parties?

Is there a necessity for such a coordinator?

Not a single person in our Tiki Model, but all devels are requested to have a bigger picture in their mind and tiki teams coordinate by their own topics?

1.1.2.7.1. Performance

Generally there is no coordinator. Performance is also very broad - good performance for shared hosting is very different from that for dedic. servers/cloud instances. Different people have different interest areas.

1.1.2.7.2. Packaging

Windows platform, Greg has been helping

Most users are on GNU/Linux but noone is working on packaging for distro - last time was with Debian a long time ago by changi.

1.1.2.8. Themes

Gary has been leading Themes

Synergiq (Nelson's company) has been helping to fund Gary's time.

1.1.2.9. Security

Pete has been volunteering but he has limited time to be the only coordinator or to lead it

Problem with security is that it requires short response time, which is difficult for any one person right now

1.1.2.10. Wishlist

Pascal was helping out Marc, and together they have been successful for a while but they both need more support.

1.1.2.11. Language

Olaf volunteered for a while but also needs help.

1.1.2.12. Community Outreach

Marc and Synergiq Solutions (Nelson's company) has done OSCON

JM has done FOSDEM

1.1.3. Tikifests

Torsten/Frank organizing TIkifestDevOps in Germany

1.1.3.1. Community Coordination

Responding to request for information from new users, whether forum or users list

Just helping everyone to know where to go for the right information. Everyone has traditionally either email devlist, and if that does not work, they email Marc to redirect them.

1.1.3.1.1. Legal

Nelson has been helping together with Steve, but again if other than bare minimum, unfortunately does not have bandwidth to do more.

Do we want to continue student lawyers from WVU

Some aspects, e.g. terms of service etc could do with some help

1.1.3.1.2. Communications

Rick has been helping with info.tiki.org and other "news releases", but he might need some help with that in 2014+

1.1.4. New tasks roles

1.1.4.1. Tiki free-for-limited-time hosting: offer free tiki site to get new admins self-trained testing it

In my case , I've recently had some dicussions in some organizations where people want to move to Wordpress 3.x instead of Tiki because they know the wordpress synax and don't want to learn new syntax of way to handle things (Tiki), it is very usable, they can use "markdown", and wordpress 3.x became some sort of full CMS, and not just a blog. Some devs tried Tiki in the past and they didn't get to understand how to set up a site they wanted to create, etc. This might change with the setup wizards since Tiki12, but we need people to know them, try them, to improve our reputation that Tiki may be too complicated to set up for new admins without external guidance.

That's why I've been thinking that as a community, we would benefit in the mid and long run it we were able to offer a way for new admins to set up a Tiki for free hosted by us for some months (1 year?), to reduce the barrier of people loosing the fear to learn the wiki syntax in Tiki, or get to know that wysiwyg exists and it's real state-of-the-art, or wikilingo-stable in the future, experience the sensation to set up their site self-guided with the Admin and Profile wizards, etc. After that free time, they would need to pay to the community (or whoever consultant/company that did pay for the costs of that infraestructure) some amount per year to keep it up for them, or they would need to move it elsewhere.

I wonder how much would cost to set up something like we have nowadays through show.t.o for bugs, but for users willing to get a free tiki for them for that amount of time. Any clue anyone? (Jyhem, maybe?)

Setting it up is not too costly, we can basically clone show. It then needs a control server, which for show is dev. So there's the main work. Creating Workflow in a Tiki with a Tracker for people to set up their site. And the main costs then are probably involved in running it: checking for spammers, dealing with high traffic sites (show is looooow traffic), etc. . I agree with amette, but I would still suggest adding more security, such as having separate mysql credentials for each instance, and provide backups. {user}

1.1.5. Are current Teams the way to continue?

This is mainly a structure that was created by Marc, and he had discussed it with Nelson/Pascal and probably others, and is a very good list of conceivably everything that would be nice to be done in Tiki. But teams haven't been getting everything done there, at least so far. See Teams.

Related question: Is it better to have an empty "team" in hope that someone may join/lead?

Yes, imho, since this way, if a person wants to contribute, and this person can contribute his/her limited time in 3 different areas, that person can choose to help in the area that needs more help, because no one or only one person is taking care of it, and it was clearly stated which areas needed more help.

Maybe Teams is the wrong word. Maybe we just need to call it "How you can contribute" instead?

To me the word "teams" is not that bad. The problem is not the naming, imo, but getting people to be really committed to help in that area. Writing someone else name in one time is not enough for this person to get committed to that work that needs to be done. Motivation... Maybe the Recognitions and Rewards (with badges and all that) within the Tiki.org site can help to get other people to be more commited to contribute?

Maybe there are too many Teams?

I think there is a real benefit in having teams that have more people in them so the social aspect of working together is achieved. It will make sense to aggregate the teams into 2 or maximum 3 teams, perhaps according to the structure below "Alternative way to group roles"

1.1.5.1. Team guidelines

Which should be the minimum guidelines for Teams, in order to have effective bottom-up teams working?
Something like the 3 rules for tiki devs. Some people might consider that we don't need them with the right people in teams. But things are more complex, rules also guide new members while they get in, etc. So maybe we need the 3 guidelines for tiki teams, in order to guide teams to perform with a minimum effectiveness while they learn by practice to work as an effective team, etc.

Here there is a proposal (please improve):

"Define your goals for the next period and report assessment at the end"

Write your goals for the next time period (for instance, 12 months) and review at the end of the period how much did you achieve them, in order to improve the goals for the next period. Make a short written report and communicate it into an open & recorded webinar for each time period.

"Readapt & follow the schedules as much as possible"

Do your best to get things done within the scheduled time frames and people who voluntarily decided to work in the team. Less people, and less dedication, means more modest goals until more people join your ship. More people and dedication can mean the opposite. If you lack skills to do some tasks, explicitly indicate that you need people more skilled to achieve tasks X, Y and Z., or that you require help from other teams.

"Fork and merge before loosing talent and motivated people"

When there is agreement among the team members that the team is reaching its end (no more goals to be reached within the available time frame and people involved), the team should avoid dying as such but do it s best to fork and merge in time with other teams to get the best outcome from the talent, people and initiatives going on.

Do teams need an explicit secretarian/coordinator? If yes, that should be added somehow to the team guidelines. If not so critical (some teams yes, some teams no), then it shouldn't be added as a guideline, probably.

See also About Tiki Teams. The list is split between technical (developers, sysadmins, etc.) and non technical (power users, translators, writers, etc.) and as you can see, there are more non-technical teams, so plenty of opportunities for you to get involved even if you are not a techie!

Configuration Profiles

The Configuration Profiles Team is responsible to produce a great first impression and useful out-of-the box solutions for site admins. Maintaining profiles for use cases, a coherent admin panel, and sensible defaults.

Documentation

The Documentation Team has the challenge of maintaining documentation for what Tiki does, hundreds of features, over 1000 pages, and a new release every 6 months!

Analytics

The Analytics Team is responsible for everything to do with stats, big data, etc. both in Tiki the software and Tiki as a community.

Video Authoring

The Video Authoring Team involves everything to do with videos in Tiki, e.g. interviews, how-to instructional videos, etc..

Finance

Consulting Ecosystem

The Consulting Ecosystem Team is all about fostering healthy growth of the network of companies that conduct business using/around Tiki, which includes increasing the number of full-time Tiki consultants and making it easier for potential Tiki users to find the right consultants / service providers in the Tiki community to meet their needs.

Infrastructure

Security

The Security Team is a trusted group. This team is responsible to review security reports and to proceed to a pro-active audit at each major release. Security Team members are added by vote by the Admins following recommendations of current members.

Performance

The Performance Team is interested in high-performance and high availability of Tiki. Tiki should not cause performance bottlenecks on shared hosting, should have options to allow it to be used in highly scalable clustered environments, and high-availability configurations.

User Experience (UX) & Themes

The UX and Themes Team is responsible to make Tiki look good and be enjoyable to use for visitors and content creators, and coordinates theme development.

1.1.1. Alternative way to group roles

Basically this approach makes it clear that there is a coordinator. The coordinator facilitates and coordinates, and tries best not to do all the work but facilitates it.

1.1.1.1. Community Outreach

Defined by primary goal to get more members into Tiki Community and facilitate users

info.tiki.org

forum

user mailing list

fosdem/oscon etc...

1.1.1.2. Internal

legal

sysadmin

tiki.org e.g. monthly webinar, info about community etc...

tikifests

fundraising

1.1.1.3. Development

security

language

release

new features

testing

packaging

themes

doc.tiki.org

dev.tiki.org

devlist

etc

As we can see the Development needs the most coordination, and probably has the most impact on the quality of Tiki as a whole. i.e. get back to basics and get those right.

The other 2 roles are important too but much easier if basics "Development" are strong.

Some concerns regarding the "coordinator" approach:

We don't want the situation where the coordinator ends up being the "bad guy" who is always pushing others around

The coordinator must have enough knowledge otherwise he will be making "silly" suggestions and add overhead with little value

Some possible solutions:

Perhaps there is a way to coordinate things wiki way with more transparency, perhaps using some trackers

The main problem with pure "wiki way" is often there is no timeline. How to balance this?

Maybe the solution is simply to make sure the coordinator is experienced/has the right knowledge? Then the problem becomes how do we attract/motivate this coordinator?

About Naming: is "coordinator" the most suitable word? Alternatives?

"Coordinator" might be understood as someone on top of you (you as a simple contributor or bare team member), and that he/she has the right to tell you team members what to do or needs to be done by them.

A top-down approach.

The weight of responsibility usually resides on the coordinator, and not so much on the team members.

Something like a "Secretarian" is usually understood as someone that works for all team members, not on top of them but as a peer member, taking the responsibility to take notes on the decisions taken as a group, and what still needs to be done from agreed tasks, etc.

A bottom-up approach.

The weight of responsibility still resides on the team members, and not so much on the secretarian which is just a worker for them.

The role of secretarian should move to another member after some period of time (1 year?)

Latest Page Changes

Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.