More than one tool for collaborating on writing the Tiki CMS
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Libs, Jean-Marc
The Tiki Wiki CMS Groupware software community obviously uses Tiki itself for collaboration and knowledge management. Yet, many other software tools or infrastructures are used. I will review and explain how and why. Tiki Wiki CMS Groupware was initially released in 2002 and is still very much alive with a vibrant community. We obviously want to use Tiki itself for collaboration and knowledge management as much as possible, but the real situation is, we use a lot more tools. We leverage the fact that Tiki is part of wikisuite by using the other wikisuite software, but these still don't cover everything we use. The reasons vary from old habits to convenience or improved efficiency and they are different for each collaboration tool. I will review them and explain why we use them and how useful they are to us. Also, I will mention our plans for the future.
 So the next presentation will be with Jean-Marc, which will talk about more than one tool for collaborating on writing the TikiCNX. So hello, Robert. So this is not about one specific product, contrary to the others. It's about sharing our experience from the TikiWeekCMS group, the software community, about producing collaborative tools and also collaborating and what we use among ourselves. The reason I'm here is because I've been really interested in open source and internet since a very long time. I discovered Tiki and I immediately felt part of the Tiki community. And since 2011, I professionally work for the Tiki, well, as a Tiki consultant. So that's not the main topic. There's more here on the link if you're really interested in my, in me. So what does our viewpoint come from? The Tiki community I'm talking about produces some open source software, which is over one million lines of code. We do major releases every eight months. Every free release is a long-term support version, which is supported about five years. The project started nearly 20 years ago by Luis Alguerice and he stayed some years and he left the project afterwards. He's not among us anymore. So that community, it's community managed open development software. It is not led by any single company. We have a number of us who are consultants, managed for hire, but we all have our own customers. It's not, there's no central point. It's not a company which manages anything. So there's no single company, as I said. There's no benevolent dictator. There's not even the initial offer. So communication is the only thing that keeps us together. So it's really crucial. Without communication, there's just no community. And yeah, and we are very open. The way we work is we are really open. Anyone can contribute. That's what version control systems are for. The Wikiway of writing software, you want to add it if it's really bad and causes problems, it can always be rolled back. So obviously, I guess everybody knows the sentence, eat your own dog food, which means that you're never going to convince anyone to use your software if you're not using it yourself. And the second reason why you have to use it as much as possible is that's how you improve it. That's how you see what people do with it when you are among those people. And then we improve it. We add things. We fix it. That's great. There's about Tiki, the special thing about Tiki, it's all inbuilt. So at least among the community, we never have to argue about which plugin we are going to use. We have many plugins that all the features are there, they're active or they're not active. We can use whatever we like. So we use the forums as such in order to communicate as well as forums are for. We also have Wiki pages and documents, which means which we use a lot because that's where we have our documentation for users on one side. We have technical documentation on another one. We also have to discuss marketing stuff, which we as an open source company are not really great at, but we try to. And we share promotional information for making t-shirts or stuff like that. They're all shared and downloadable. All those websites are federated. There's the single login, et cetera. It works well. People use that. It's really, it's, as usual, the documentation for users is a bit late usually, but it gets done. We have some, what we call a tracker, which is really a database because it started as a bug tracker and then it expanded. That's where we share, well, that's where people report bugs and also ask for new features. That really works fine because we can discuss them, we can fix them, we know what remains to be done, et cetera. We also have articles feature. That's mostly for communication. When we have a new release, someone gets an article and we share it on social media and all that. We have a blog feature, which is rather underused. It's used by the assistance administrator's team, the people who manage our infrastructure. There is some kind of a wiki page structure and restricted documents and a restricted blog. The blog is there because it's less powerful than articles. All we want about this is to do an operation report. You need a title. You need to say when it was done and you need to describe what was done so that the other scissors know what has been done and they can look at how it was done so they can get an inspiration and all that. No need for anything more complicated than that. That's why we use the blog for that. We have comments. Comments can be linked to any of the above. You might wonder why we need comments when, for example, anyone can edit the wiki pages. By anyone, I didn't mention it yet. Anyone can register, create an account and contribute. There's no real problem. Sometimes we get spammers this way and we just roll everything back. It's a wiki. The comments are for discussing documents. Some stuff like the Wichis tracker are commented that's obvious. The issue you have with wiki pages is that everybody can contribute on some topic like a technical topic, et cetera, but people are polite. They add their opinion. They never remove anything from anyone else. They might prefer to comment rather than change the content because they're not so sure, et cetera. That's why both are needed. We also, it's a way of communication. We've used tiki to let people provide added information about themselves or about why they're in the community or what they look like in a photo when they register. Another technical feature, which is, of course, really important is that when you have an account, you can set watches on what you're interested in so that you get email when something happens because you're not going back every day on the site. That's basically everything tiki provides for us. I'm not saying it's not working. We use it. We like it. We improve it. But there's more. We also have historic tools. We use that because I told you it's nearly 20 years old project. SourceFox was really fashionable at one time, I tell you, before they got technical and ethical issues. We still have used that for two things. First, the Subversion Repro, which is being migrated to GitLab, but it's still going to stay here because we have those long-term support versions, which we promise people that they will get upgrades for five years. It will switch to being read only, but still available so that people can upgrade their website and get the newest security fixes and bug fixes. They provide mailing lists, which we use actually. We have a developer's mailing list, which is very successful. That's basically where we discuss what we want to do, et cetera. It's even the one when we say, okay, I want to start this. Here is the Wiki page about it, but still that's how we get the information. That works fine. Of course, there's this issue that those mailing lists, people complain that, yeah, but if you're not registered on the mailing list, you don't get the information, et cetera. But we have that feature that we can synchronize it with a forum. I told you about the forum. One of the forums has the same content. You can, it shows up in the forum when you mail, and you can answer in the mailing list and we get it in the forum. We get it in the mailing list. We have another one for users, Total Failure, because people will just ask on the developers' mailing list, they get better answers for more knowledgeable people. We have a mailing list, it just gives all the commits, everything that changes in the code and we can review it. We have the div.txt, a lot of people actually use it and they answer there in order to comment on this because that shouldn't be this way or that's useful. Historic non-source tools, yeah, we are on IRC and some of us like that. It works well. We have zero maintenance about that. Only issue is three years ago, I think they had a massive dose. They had trouble, so we use it much less. It works better again, but that's how we have frequent debates about what's best. Nothing is best. The people who go on the forums are not the same people who answer questions on IRC. It just spreads the knowledge. So XMPP also is great. So another thing that's really important is the TikiFest. TikiFest is when people who don't usually meet meet like, you know, there's first them, some of us are here, some of us came some days before and we meet. It's not a technical issue. It's just really important to do that because once you know the people, you can go back to sending them emails and it's just easier because you know what the person will understand how you communicate. It's just simpler. And also you can ask questions like why are they in the project? Are they really at a full time? Are they just curious? It's another non-technical thing to keep in mind. TikiFest are kind of expensive. So we also do online meetings. And it's been mentioned, one of the great things about Open Source Software is don't hesitate to reach to other projects for collaborations. They're open. We had a collaboration with Big Group Button so that got us integration. You are logged in on the Tiki site for the meetings and then you click and you get in the Big Group Button room and you have your own name. And if you didn't register, it shows guest. We do that for monthly around table meetings which started as webinars but it's not really presentations. One hour, very short topics, you know, like hey, next month there's first them who's coming. And one hour of presentations, anyone has some new things to present to how it's done. And new features are usually easier to present on a webinar because then it's usually someone else who will have to write the user documentation. We are mostly volunteers and that, you know. Tiki Admin Group meetings. Oh, I didn't mention that. We have an association which as I said, as you may have figured out, the community created the association. The association did not create the community. It's for holding the copyright to the name and dealing with server and stuff. So they meet every three months. We've also really like GC Meet also. We've been in contact with them but there was no real reason for doing any collaboration because it just works. And for a time, Big Blue Button had took a long time before they switched from Flash to HTML5. So now we, and we were not really happy and we were really happy to have an alternative. So yeah, now Big Blue Button runs fine and it still is recorded on our servers which is cool because GC Meet doesn't have that. We could record that but I think it goes to Google. We obviously don't like that. I mean, I'm happy for them that they have that option. It's clearly the thing to do but we don't want to use it. Another way of collaborating is that Tiki is part of WikiSuite which is a project about providing all the needs of a small company only with open source stuff. So we get in touch with people or other projects and we get contacts with some of those other projects. So we have that XMPP thing which competes with IRC because it is more modern. And we have people, we get in touch with GUS especially about having that open fire server, ConverseGS which gives us a web-based interface to the XMPP which you can get on WikiSuite.chats and Pade is an app which is also a browser-based but it has its own window. That gets us because I think XMPP as a protocol has a lot of things for it. It's federated, it has everything. The focus I think personally is the clients right now for more use of it. Same thing is also part of it so we use it to spread backups and all that. And yes, so the message again is yes, we discovered that even though we provide collaboration tools, a good thing is to have a lot of them and also some we have for historical reason and we want to change etc. It's not the same ones as 10 years ago, it changes. So we want to change also, we also have plans. I told you we are not going to stay on Subversion, not even on SourceForge but that takes time for change management reasons. We want to really improve our mail, the mail integration capability. We have SIFT integration, GMAP in Tiki and in Tiki21 which is the one we just branched yesterday. We have Cardav and Cardav Dev and as usual now that we have them there, we will improve our view using them. As a summary, how does it work generally speaking for us, when we want to know where we want to go and make plans, the things that work great because at some point you have to make a decision are the TikiFests when there's enough of us and the others online at the end of the decision you can say, okay we all kind of agree that that's what we do. We have the development mainly because everybody is on it basically so you know what's going on, it's a nice place and it is recorded, we have all of that. Wiki pages are also great when we don't want, when we don't know where we want to go and we want more feedback. The Wish Tracker is also one of those ways that new stuff pop up because Pickup will ask for and we do them or not. And there are those monthly roundtable meetings. The tag is Tiki Admin Group which also gets things for plans and when we want to discuss how we do things, well there's a lot of discussion about commits which were done and people just start a threat about that. Or again the DevTiki or Wiki pages just say okay how do we do that? Which is basically so. Did I leave time for questions? So are there any questions about or unclear? So in the Tiki community you have kind of a limited amount of developers or development workforce. So how do you manage to basically provide new features to the project while still supporting some of the features that you support as part of the kind of backward compatibility strategy or long term support strategy? So one of the reasons we are really happy with the way Tiki community works is that a lot of us do that as paid consultants and that means we have our customers. The question was we have limited development force. How do we spread the work and decide on support old stuff and add new stuff? Part of our job is it's very powerful software, it gets really complicated. People like to have a consultant do it for them because they have another work they're good at which they want to focus on. But they have complex needs. So basically it's often Tiki does 90% of what they want and one of us, they pay one of us to add 10% and we contribute that 10% to the community. So that's how we get the new things. As for maintaining the old things, whoever uses the old things will complain that they are broken on upgrade. They also want upgrades because okay, we stay five years, it's not that long. They come back, they want a new version. They say, thanks for the new stuff but I like the old one and you just broke it, it seems, or it could be better. And so there's no central point where people decide you will do this, you will do this. If nobody uses something, then nobody will touch it. And after a while we say, okay, this is deprecated.
 So the next presentation will be with Jean-Marc, which will talk about more than one tool for  collaborating on writing the TikiCNX.  So hello, Robert.  So this is not about one specific product, contrary to the others.  It's about sharing our experience from the TikiWeekCMS group, the software community,  about producing collaborative tools and also collaborating and what we use among ourselves.  The reason I'm here is because I've been really interested in open source and internet  since a very long time.  I discovered Tiki and I immediately felt part of the Tiki community.  And since 2011, I professionally work for the Tiki, well, as a Tiki consultant.  So that's not the main topic.  There's more here on the link if you're really interested in my, in me.  So what does our viewpoint come from?  The Tiki community I'm talking about produces some open source software, which is over one  million lines of code.  We do major releases every eight months.  Every free release is a long-term support version, which is supported about five years.  The project started nearly 20 years ago by Luis Alguerice and he stayed some years and  he left the project afterwards.  He's not among us anymore.  So that community, it's community managed open development software.  It is not led by any single company.  We have a number of us who are consultants, managed for hire, but we all have our own  customers.  It's not, there's no central point.  It's not a company which manages anything.  So there's no single company, as I said.  There's no benevolent dictator.  There's not even the initial offer.  So communication is the only thing that keeps us together.  So it's really crucial.  Without communication, there's just no community.  And yeah, and we are very open.  The way we work is we are really open.  Anyone can contribute.  That's what version control systems are for.  The Wikiway of writing software, you want to add it if it's really bad and causes  problems, it can always be rolled back.  So obviously, I guess everybody knows the sentence, eat your own dog food, which means  that you're never going to convince anyone to use your software if you're not using it  yourself.  And the second reason why you have to use it as much as possible is that's how you  improve it.  That's how you see what people do with it when you are among those people.  And then we improve it.  We add things.  We fix it.  That's great.  There's about Tiki, the special thing about Tiki, it's all inbuilt.  So at least among the community, we never have to argue about which plugin we are going  to use.  We have many plugins that all the features are there, they're active or they're not active.  We can use whatever we like.  So we use the forums as such in order to communicate as well as forums are for.  We also have Wiki pages and documents, which means which we use a lot because that's where  we have our documentation for users on one side.  We have technical documentation on another one.  We also have to discuss marketing stuff, which we as an open source company are not  really great at, but we try to.  And we share promotional information for making t-shirts or stuff like that.  They're all shared and downloadable.  All those websites are federated.  There's the single login, et cetera.  It works well.  People use that.  It's really, it's, as usual, the documentation for users is a bit late usually, but it gets  done.  We have some, what we call a tracker, which is really a database because it started as  a bug tracker and then it expanded.  That's where we share, well, that's where people report bugs and also ask for new features.  That really works fine because we can discuss them, we can fix them, we know what remains  to be done, et cetera.  We also have articles feature.  That's mostly for communication.  When we have a new release, someone gets an article and we share it on social media and  all that.  We have a blog feature, which is rather underused.  It's used by the assistance administrator's team, the people who manage our infrastructure.  There is some kind of a wiki page structure and restricted documents and a restricted  blog.  The blog is there because it's less powerful than articles.  All we want about this is to do an operation report.  You need a title.  You need to say when it was done and you need to describe what was done so that the other  scissors know what has been done and they can look at how it was done so they can get  an inspiration and all that.  No need for anything more complicated than that.  That's why we use the blog for that.  We have comments.  Comments can be linked to any of the above.  You might wonder why we need comments when, for example, anyone can edit the wiki pages.  By anyone, I didn't mention it yet.  Anyone can register, create an account and contribute.  There's no real problem.  Sometimes we get spammers this way and we just roll everything back.  It's a wiki.  The comments are for discussing documents.  Some stuff like the Wichis tracker are commented that's obvious.  The issue you have with wiki pages is that everybody can contribute on some topic like  a technical topic, et cetera, but people are polite.  They add their opinion.  They never remove anything from anyone else.  They might prefer to comment rather than change the content because they're not so sure, et  cetera.  That's why both are needed.  We also, it's a way of communication.  We've used tiki to let people provide added information about themselves or about why  they're in the community or what they look like in a photo when they register.  Another technical feature, which is, of course, really important is that when you have an  account, you can set watches on what you're interested in so that you get email when something  happens because you're not going back every day on the site.  That's basically everything tiki provides for us.  I'm not saying it's not working.  We use it.  We like it.  We improve it.  But there's more.  We also have historic tools.  We use that because I told you it's nearly 20 years old project.  SourceFox was really fashionable at one time, I tell you, before they got technical and  ethical issues.  We still have used that for two things.  First, the Subversion Repro, which is being migrated to GitLab, but it's still going to  stay here because we have those long-term support versions, which we promise people that they  will get upgrades for five years.  It will switch to being read only, but still available so that people can upgrade their  website and get the newest security fixes and bug fixes.  They provide mailing lists, which we use actually.  We have a developer's mailing list, which is very successful.  That's basically where we discuss what we want to do, et cetera.  It's even the one when we say, okay, I want to start this.  Here is the Wiki page about it, but still that's how we get the information.  That works fine.  Of course, there's this issue that those mailing lists, people complain that, yeah, but if  you're not registered on the mailing list, you don't get the information, et cetera.  But we have that feature that we can synchronize it with a forum.  I told you about the forum.  One of the forums has the same content.  You can, it shows up in the forum when you mail, and you can answer in the mailing list  and we get it in the forum.  We get it in the mailing list.  We have another one for users, Total Failure, because people will just ask on the developers'  mailing list, they get better answers for more knowledgeable people.  We have a mailing list, it just gives all the commits, everything that changes in the  code and we can review it.  We have the div.txt, a lot of people actually use it and they answer there in order to comment  on this because that shouldn't be this way or that's useful.  Historic non-source tools, yeah, we are on IRC and some of us like that.  It works well.  We have zero maintenance about that.  Only issue is three years ago, I think they had a massive dose.  They had trouble, so we use it much less.  It works better again, but that's how we have frequent debates about what's best.  Nothing is best.  The people who go on the forums are not the same people who answer questions on IRC.  It just spreads the knowledge.  So XMPP also is great.  So another thing that's really important is the TikiFest.  TikiFest is when people who don't usually meet meet like, you know, there's first them,  some of us are here, some of us came some days before and we meet.  It's not a technical issue.  It's just really important to do that because once you know the people, you can go back to  sending them emails and it's just easier because you know what the person will understand  how you communicate.  It's just simpler.  And also you can ask questions like why are they in the project?  Are they really at a full time?  Are they just curious?  It's another non-technical thing to keep in mind.  TikiFest are kind of expensive.  So we also do online meetings.  And it's been mentioned, one of the great things about Open Source Software is don't  hesitate to reach to other projects for collaborations.  They're open.  We had a collaboration with Big Group Button so that got us integration.  You are logged in on the Tiki site for the meetings and then you click and you get in  the Big Group Button room and you have your own name.  And if you didn't register, it shows guest.  We do that for monthly around table meetings which started as webinars but it's not really  presentations.  One hour, very short topics, you know, like hey, next month there's first them who's  coming.  And one hour of presentations, anyone has some new things to present to how it's done.  And new features are usually easier to present on a webinar because then it's usually someone  else who will have to write the user documentation.  We are mostly volunteers and that, you know.  Tiki Admin Group meetings.  Oh, I didn't mention that.  We have an association which as I said, as you may have figured out, the community created  the association.  The association did not create the community.  It's for holding the copyright to the name and dealing with server and stuff.  So they meet every three months.  We've also really like GC Meet also.  We've been in contact with them but there was no real reason for doing any collaboration  because it just works.  And for a time, Big Blue Button had took a long time before they switched from Flash  to HTML5.  So now we, and we were not really happy and we were really happy to have an alternative.  So yeah, now Big Blue Button runs fine and it still is recorded on our servers which  is cool because GC Meet doesn't have that.  We could record that but I think it goes to Google.  We obviously don't like that.  I mean, I'm happy for them that they have that option.  It's clearly the thing to do but we don't want to use it.  Another way of collaborating is that Tiki is part of WikiSuite which is a project about  providing all the needs of a small company only with open source stuff.  So we get in touch with people or other projects and we get contacts with some of those other  projects.  So we have that XMPP thing which competes with IRC because it is more modern.  And we have people, we get in touch with GUS especially about having that open fire  server, ConverseGS which gives us a web-based interface to the XMPP which you can get on  WikiSuite.chats and Pade is an app which is also a browser-based but it has its own window.  That gets us because I think XMPP as a protocol has a lot of things for it.  It's federated, it has everything.  The focus I think personally is the clients right now for more use of it.  Same thing is also part of it so we use it to spread backups and all that.  And yes, so the message again is yes, we discovered that even though we provide collaboration  tools, a good thing is to have a lot of them and also some we have for historical reason  and we want to change etc.  It's not the same ones as 10 years ago, it changes.  So we want to change also, we also have plans.  I told you we are not going to stay on Subversion, not even on SourceForge but that takes time  for change management reasons.  We want to really improve our mail, the mail integration capability.  We have SIFT integration, GMAP in Tiki and in Tiki21 which is the one we just branched  yesterday.  We have Cardav and Cardav Dev and as usual now that we have them there, we will improve  our view using them.  As a summary, how does it work generally speaking for us, when we want to know where we want  to go and make plans, the things that work great because at some point you have to make  a decision are the TikiFests when there's enough of us and the others online at the  end of the decision you can say, okay we all kind of agree that that's what we do.  We have the development mainly because everybody is on it basically so you know what's going  on, it's a nice place and it is recorded, we have all of that.  Wiki pages are also great when we don't want, when we don't know where we want to go and  we want more feedback.  The Wish Tracker is also one of those ways that new stuff pop up because Pickup will  ask for and we do them or not.  And there are those monthly roundtable meetings.  The tag is Tiki Admin Group which also gets things for plans and when we want to discuss  how we do things, well there's a lot of discussion about commits which were done and people just  start a threat about that.  Or again the DevTiki or Wiki pages just say okay how do we do that?  Which is basically so.  Did I leave time for questions?  So are there any questions about or unclear?  So in the Tiki community you have kind of a limited amount of developers or development  workforce.  So how do you manage to basically provide new features to the project while still supporting  some of the features that you support as part of the kind of backward compatibility strategy  or long term support strategy?  So one of the reasons we are really happy with the way Tiki community works is that  a lot of us do that as paid consultants and that means we have our customers.  The question was we have limited development force.  How do we spread the work and decide on support old stuff and add new stuff?  Part of our job is it's very powerful software, it gets really complicated.  People like to have a consultant do it for them because they have another work they're  good at which they want to focus on.  But they have complex needs.  So basically it's often Tiki does 90% of what they want and one of us, they pay one  of us to add 10% and we contribute that 10% to the community.  So that's how we get the new things.  As for maintaining the old things, whoever uses the old things will complain that they  are broken on upgrade.  They also want upgrades because okay, we stay five years, it's not that long.  They come back, they want a new version.  They say, thanks for the new stuff but I like the old one and you just broke it, it seems,  or it could be better.  And so there's no central point where people decide you will do this, you will do this.  If nobody uses something, then nobody will touch it.  And after a while we say, okay, this is deprecated.
more_than_one_tool_tiki_0_167.png more_than_one_tool_tiki_168_407.png more_than_one_tool_tiki_408_527.png more_than_one_tool_tiki_528_1127.png more_than_one_tool_tiki_1128_1907.png more_than_one_tool_tiki_1908_4955.png more_than_one_tool_tiki_4956_13043.png more_than_one_tool_tiki_13044_13127.png more_than_one_tool_tiki_13128_13439.png more_than_one_tool_tiki_13440_14663.png more_than_one_tool_tiki_14664_17111.png more_than_one_tool_tiki_17112_17975.png more_than_one_tool_tiki_17976_18203.png more_than_one_tool_tiki_18204_18623.png more_than_one_tool_tiki_18624_18719.png more_than_one_tool_tiki_18720_18803.png more_than_one_tool_tiki_18804_18851.png more_than_one_tool_tiki_18852_18899.png more_than_one_tool_tiki_18900_19463.png more_than_one_tool_tiki_19464_20051.png more_than_one_tool_tiki_20052_23447.png more_than_one_tool_tiki_23448_25811.png more_than_one_tool_tiki_25812_27419.png more_than_one_tool_tiki_27420_28931.png more_than_one_tool_tiki_28932_29627.png more_than_one_tool_tiki_29628_30167.png more_than_one_tool_tiki_30168_31247.png more_than_one_tool_tiki_31248_32759.png more_than_one_tool_tiki_32760_33491.png more_than_one_tool_tiki_33492_33647.png more_than_one_tool_tiki_33648_33768.png