Loading...
 

CommunityCoordinationPlanning

This page is an archive of ideas


SWOT Analysis for 2014 Spring

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

Strengths

Things we are doing well
  1. New features
  2. Product renewing
  3. New themes will be available for Tiki13+ when Bootstrap revamp is finished.
  4. Wizards since Tiki12 help new admins to get started more easily.
  5. Monthly webinar meetings have been useful
  6. Release cycle is working
    1. Release process and documentation are improved on each release
    2. Release team is stable
    3. Roles are getting more and more flexible (knowledge is spread)

Weaknesses

Things we are doing not so well
  1. Release coordination is always stressful
    1. It is the time when we feel how few people we are
    2. Bug and regression fixing is painful
  2. Documentation
    • doc.t.o (online)
    • Books (printed, ebooks). We need them updated to LTS version.
  3. Helping new users to find online what they need
  4. Information overload/hard to find on all tiki.org sites
  5. Keeping critical servers with just one sysadmin (high bus factor, and low resilience)
  6. Setting up servers in a way that other admins can not help with when we need it.

Opportunities

  1. Promote using the new setup wizards (Profiles Wizard, Admin Wizard) to have most new Tikis set up easily without needing an expert with them.
  2. 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?
  3. 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.
  4. Set up some server infraestructure (like the new server for nextdev.t.o & nextdoc.t.o) with TikiSuite to dogfood it?
  5. 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).
  6. 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 Nelson Ko : 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

  1. Loosing sites and organizations because too complicated to learn how to set up a site without human guidance from an expert
  2. Too complicated to get a test site hosted and working for potential new site admins
  3. Diverging too much from de-facto standards in some communities:
    • "Markdown" syntax being used in github, wordpress, moodle, ...
  4. 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)
  5. not enough people using wysiwyg or anonymous edits, and thus, bugs that produce content to be lost were detected late are still unfixed.
    • See Wysiwyg-related: wish5186}, wish5083. See Anon edits related: wish5004

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. Xavier de Pedro

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 Xavier de Pedro 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? Xavier de Pedro

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.

  • 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 Xavier de Pedro , 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. amette . 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. Xavier de Pedro


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? Xavier de Pedro


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" Nelson Ko

1.1.5.1. Team guidelines

This is a proposal being drafted during TikiFest2014-Toronto-Tiki13Alpha


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

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!

Thinking about participating? Talk to us on IRC.

Tiki Admin Group

The Tiki Admin Group is responsible for governance, overall coordination and all the rest including whatever that might fall between the cracks biggrin.

Non-Technical teams

i18n (translations)

i18n Team is everything related to language strings, translations and localizations (l10n) and increase the number of languages in Tiki.

Wishlist Triage (bug reports, feature requests)

The Wishlist Triage Team reviews patches, bug reports and feature requests and prioritizes and categorizes them. They just triage but don't fix. They identify potential contributors and encourage them to go beyond bug reporting. Team leaders: luciash d' being and Roberto Kirschbaum

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


The Legal Team handles everything to do with copyrights, licenses, etc. for content and software and helps the Tiki Software Community Association.

Fundraising

The Fundraising Team handles everything to do with donations, advertising and sponsors for the Tiki Software Community Association.

Finance

The Finance Team handles everything to do with accounting, and managing the assets of the Tiki Software Community Association (Ex.: domain names)

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.



Community Building

The Community Building Team focuses on making Tiki better as a community, and coordinates all efforts related to user support, volunteers coordination, welcoming new users, TikiFests, Webinars, etc.


Dogfood

The Dogfood Team ensures that all *.tiki.org sites are configured and working well, according to the software engineering principle of "Eating your own dog food". Team leaders: luciash d' being and Roberto Kirschbaum

Branding

The Branding Team involves market analysis, brand management and providing community tools for a coherent and efficient message.



Communications

The Communications Team is responsible primarily for our external message (press releases, newsletters, social media, etc.)

Branding vs communications vs community building vs dogfood

We spun off Branding Team from Communications Team as a separate team. There is also an overlap with the Community Building Team. And more recently, a Dogfood Team was added. The following table provides some insight on the differences.

Publishing official News about Tiki Communications Team
Our official presence on Twitter, Facebook, etc. Communications Team
Generally promoting Tiki on social media Community Building
Posting articles about Tiki on your own blog/site Community Building
For people to have a good impression when they visit Branding
For people to understand what we do Branding
Developing a style guide for visual and textual communication Branding
To have lots of traffic and good SEO Communications Team can coordinate but everyone can help
Answering people's queries on *.tiki.org (content) Community Building Team
Making sure *.tiki.org is optimally configured (config) Dogfood Team

Technical Teams

Release

The Release Team is about managing the process to achieve timely releases of Tiki, and coordinating throughout the community as almost all Teams should participate actively to each release. A balance needs to be maintained: "Don't rush, yet don't slow down". See all the Contributions of each Team to the release process.

Packaging

The Packaging Team involves making Tiki easily deployable on various platforms and 1-click installers.



Infrastructure

The Infrastructure Team is responsible for *.tiki.org hosting, server administration, domains, uptime, etc.

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.

Continuous Integration

The Continuous Integration Team focuses on all automation aspects to catch bugs early and to keep the quality high (unit tests, etc.)


Developer

The Developers Team are the umbrella group responsible to make Tiki better as an application. Please see how to get commit access.



Related

Alias

1.1.6. 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.6.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.6.2. Internal

  • legal
  • sysadmin
  • tiki.org e.g. monthly webinar, info about community etc...
  • tikifests
  • fundraising

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










Alias names of this page

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

Page last modified on Monday 01 February 2016 02:10:14 GMT-0000

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.