SWOT Analysis for 2014 Spring

Why a good SWOT analysis is important (improve it!): http://en.wikipedia.org/wiki/SWOT_analysis

1.1.2. Ongoing tasks/roles

Definition: Gardener means the person who takes care of the content, as opposed to the person who takes care of the invisible technical stuff (upgrades, backups, etc.).

1.1.2.1. tiki.org wiki gardener

• No one really taking the lead of wiki gardener

1.1.2.2. Documentation coordinator

• Vacant since for a while.
• Maybe we need more people in the Documentation team, and not that much just a one-person coordinator.

1.1.2.3. Dev.tiki.org wiki gardener

• No one really taking the lead of wiki gardener
• Perhaps can be combined with lead developer role?

1.1.2.4. info.tiki.org

• call it marketing, or info, this is the 1st place new visitors tend to arrive at. there is currently not really anyone leading improvements so it's gotten somewhat dated.

1.1.2.5. Sysadmin & Server management

See current SysAdmin Guidelines

1.1.2.5.1. Sysadmin guidelines proposal drafted during TikiFest2014-Toronto-Tiki13Alpha

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

Community Servers

This list could/should be merged with the info at: http://tiki.org/Domains

Domain name management

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

1. "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.
2. "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.
3. "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: http://tiki.org/Teams

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

Community Coordination Planning | Coordination Planning | Community Coordination | CoordinationPlanning | CommunityCoordination | Coordination