[xwiki-devs] Questions concerning the development of XWiki, Round 2
Hello again! First of all, let me express my thanks to all of you who joined in on this thread (started at http://lists.xwiki.org/pipermail/devs/2012-April/050416.html) to support me in my quest to better understand the way open source development works in XWiki. :) As I've mentioned in my last email, I have some more questions I would like to ask. Last time I focused on general aspects of the process, today's topics revolve around the project's architecture, roles and governance, and knowledge management. So my first question this time concerns the architectural design, and how it has evolved over time. Did the basic structure change / grow significantly since the early days of XWiki? Vincent mentioned the change from a monolithic code to small modules. Were these and other changes made in some major refactorings, or rather through steady refinement? To what degree is it an issue to keep backwards compatibility between releases? Also I am interested more closely how the functions and responsibilities are divided in the team. Caty wrote about 'very clear departments' in her last answer, and the teampage on XWiki.com lists a multitude of different and specific roles. Both of your descriptions of the testing process, however, suggests a less strict separation of tasks. So what role do the roles play? How specialized or cross-functional are the teams and people working therein? Is there a difference between XWiki.org and XWiki SAS? In a related matter, many of the role descriptions of the core developers contain manager and leadership titles. What, in practice, are the main tasks of the people managing the development? Many meritocracies have safety nets, some rules to follow or people to go to when no consensus can be reached on important topics. Did this ever occur in XWiki? What would be done in such a situation? Have either the formal roles or the informal merit people earned in a special field some kind of influence on the weight of their voice in a dispute? And last but not least some questions about the access and distribution of knowledge: XWiki features an extensive written documentation of itself and the process used in its development. What is the role then of additional, personal communication, of the proverbial informal talk at the water cooler? Is the necessary time and ceremony of written documentation always justified by making the knowledge permanently available to everyone, or can you think of exceptions? Again, every answer or comment is greatly appreciated, Martin
Hi Martin, On May 10, 2012, at 7:27 PM, Martin Schönberger wrote:
Hello again!
First of all, let me express my thanks to all of you who joined in on this thread (started at http://lists.xwiki.org/pipermail/devs/2012-April/050416.html) to support me in my quest to better understand the way open source development works in XWiki. :)
As I've mentioned in my last email, I have some more questions I would like to ask. Last time I focused on general aspects of the process, today's topics revolve around the project's architecture, roles and governance, and knowledge management.
So my first question this time concerns the architectural design, and how it has evolved over time. Did the basic structure change / grow significantly since the early days of XWiki? Vincent mentioned the change from a monolithic code to small modules. Were these and other changes made in some major refactorings, or rather through steady refinement? To what degree is it an issue to keep backwards compatibility between releases?
We've decided a long time ago (we = the committers at that time) that we preferred evolution rather than revolution. The main reason is that XWiki already had an important user base when the development team was started (before that it was just Ludovic working on it). It takes more time but it allows us to keep existing users happy. In addition we've been able to still move forward. There's a Joel Spolsky blog about this topic: http://www.joelonsoftware.com/articles/fog0000000069.html I don't have any figure I can prove but I'd say we've modified a bit more than half of the code in a 5 years time span (maybe up to 75%). I can cite 2 examples of relatively large refactorings we've done without breaking backward compatibility: * The Rendering module. XWiki had a wiki syntax initially and we wanted to fully rewrite the code that takes an input in that syntax and generate HTML out of it. So we created a new Rendering engine that can take any input in any syntax and generate an output in any other syntax (see http://rendering.xwiki.org). And we added polyglot support in XWiki (ie the ability to support several wiki syntaxes), and introduced XWiki Syntax 2.0. * The WYSIWYG editor. We were using TinyMCE and switched to our own editor that we wrote from scratch. If you're interested we can explain the reason… Then we have a lot of smaller refactorings. We can go into more details if you're interested. The only big part that hasn't been refactored yet is the core Model. I'd really like to tackle this and we've started designing the new model a bit but it's complex and requires a long period of focused time which I personally haven't been able to get so far. We're very serious on backward compatibility and most wiki pages back from 5 years ago still work on the latest version. We've defined a precise strategy to ensure we don't break backward compatibility: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackward... If you're interested in how we came up with this, it should be easy to find the mailing list threads about it on xwiki.markmail.com
Also I am interested more closely how the functions and responsibilities are divided in the team. Caty wrote about 'very clear departments' in her last answer, and the teampage on XWiki.com lists a multitude of different and specific roles. Both of your descriptions of the testing process, however, suggests a less strict separation of tasks. So what role do the roles play? How specialized or cross-functional are the teams and people working therein? Is there a difference between XWiki.org and XWiki SAS?
At the open source project level we have only 2 roles: * contributors: anyone contributing as defined here: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing * committers: people who have right access to the SCM and who can vote, see http://dev.xwiki.org/xwiki/bin/view/Community/Committership Committers decide what they want to work on. Some can be more design-oriented, others more test-oriented, etc. At XWiki SAS we have more roles and a more traditional structure. Tech roles: * CTO (me ;)) * Tech Lead or Senior Dev * Web Developers * Back end Developer * Tester * QA engineer * Designer
In a related matter, many of the role descriptions of the core developers contain manager and leadership titles.
Hmm. Do you have a link? AFAIK we just have committers.
What, in practice, are the main tasks of the people managing the development?
There's nobody managing the development ;) We're auto-managed. Committers make proposals or start votes and others discuss and vote. We do stuff by collegial agreements.
Many meritocracies have safety nets, some rules to follow or people to go to when no consensus can be reached on important topics. Did this ever occur in XWiki? What would be done in such a situation?
It happens rarely. We do frequently don't agree on some details. The proposals or vote is then discussed and amended with a new proposal/vote. Example: * First vote: http://markmail.org/thread/56v5thsj6wv7tpno * Second vote: http://markmail.org/thread/tino4ngttflc5i3s Sometimes it takes longer to reach a consensus but it's always a better result IMO. Nobody in this community votes -1 without a good reason just to bother people ;)
Have either the formal roles or the informal merit people earned in a special field some kind of influence on the weight of their voice in a dispute?
Everyone has the same vote power but then people have more influence than others through their past actions.
And last but not least some questions about the access and distribution of knowledge: XWiki features an extensive written documentation of itself and the process used in its development. What is the role then of additional, personal communication, of the proverbial informal talk at the water cooler? Is the necessary time and ceremony of written documentation always justified by making the knowledge permanently available to everyone, or can you think of exceptions?
We try to make it as easy as possible for someone external to follow the development or join the team. We also try to have a common style for writing code. This is needed before there's no ownership of the code and everyone can modify any part of the code. Also homogenous code also makes it easier to join the dev team. Of course we have lots of informal discussion on the mailing list and on IRC (and people speak with other privately too but all proposals/decisions are always made publicly). Hope it helps, -Vincent
Again, every answer or comment is greatly appreciated,
Martin
Hi Martin, here we go! On Thu, May 10, 2012 at 7:27 PM, Martin Schönberger <[email protected]>wrote:
Hello again!
First of all, let me express my thanks to all of you who joined in on this thread (started at http://lists.xwiki.org/pipermail/devs/2012-April/050416.html) to support me in my quest to better understand the way open source development works in XWiki. :)
As I've mentioned in my last email, I have some more questions I would like to ask. Last time I focused on general aspects of the process, today's topics revolve around the project's architecture, roles and governance, and knowledge management.
So my first question this time concerns the architectural design, and how it has evolved over time. Did the basic structure change / grow significantly since the early days of XWiki? Vincent mentioned the change from a monolithic code to small modules. Were these and other changes made in some major refactorings, or rather through steady refinement? To what degree is it an issue to keep backwards compatibility between releases?
I'm not very qualified to answer this one, but here goes. XWiki has had user that started using the software in its early days (I have an example from around 2006 in mind) who are still using the software today and successfully managed to upgrade from version 0.9 to version 3.5.1 and still have their wiki functional. XWiki has many enterprise users, for whom backward compatibility is very important. So the XWiki dev community has always been careful not to break too many things at once and provide an upgrade path from one version to the next. Major changes (such as the switch to a new syntax) came with a migrator to help handling them. It is sometimes tough to maintain backward compatibility, but it's a major priority of the dev team. Also I am interested more closely how the functions and
responsibilities are divided in the team. Caty wrote about 'very clear departments' in her last answer, and the teampage on XWiki.com lists a multitude of different and specific roles. Both of your descriptions of the testing process, however, suggests a less strict separation of tasks. So what role do the roles play? How specialized or cross-functional are the teams and people working therein? Is there a difference between XWiki.org and XWiki SAS?
As Vincent explained, yes, there is a difference. While the company is organized in a more traditional way, with a division of responsibilities, in the XWiki.org there are only committers and contributors, with no other formal title. Everyone is encouraged to participate according to their abilities, be that coding, documenting, testing or communicating. In addition to this, a lot of members of the community are not related to the company whatsoever. You can find out more about them here: http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame In a related matter, many of the role descriptions of the core
developers contain manager and leadership titles. What, in practice, are the main tasks of the people managing the development? Many meritocracies have safety nets, some rules to follow or people to go to when no consensus can be reached on important topics. Did this ever occur in XWiki? What would be done in such a situation? Have either the formal roles or the informal merit people earned in a special field some kind of influence on the weight of their voice in a dispute?
I don't have much to add to Vincent's answer here. The important thing to keep in mind is that when taking part to the community, your XWiki SAS title plays no part. For instance in my case, the weight of my remarks would come from my past involvement in the community (writing documentation, taking part to discussion about features, testing the product) rather my XWiki SAS role. And last but not least some questions about the access and
distribution of knowledge: XWiki features an extensive written documentation of itself and the process used in its development. What is the role then of additional, personal communication, of the proverbial informal talk at the water cooler? Is the necessary time and ceremony of written documentation always justified by making the knowledge permanently available to everyone, or can you think of exceptions?
When starting to work with a new piece of technology, even with the best documentation in the world there will be times when you will need to ask questions and have a discussion with others. This can happen in real life (and it does a lot at the office), but also through Skype or IRC. XWiki devs and users try to make themselves available to answer questions from users and newcomers, which greatly contributes to the sense of community around XWiki. Guillaume
Again, every answer or comment is greatly appreciated,
Martin _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Thank you both, again, for your answers!
Hope it helps
Yes it definitely did, and could cast aside most of my uncertainties. I have just a few quick remarks and follow-ups:
In a related matter, many of the role descriptions of the core developers contain manager and leadership titles.
Hmm. Do you have a link? AFAIK we just have committers.
I'm sorry, I guess my mistake here was not taking the separation between XWiki SAS and XWiki.org into consideration. I was referring to http://www.xwiki.com/xwiki/bin/view/Company/Team, where three Project Managers, a Team Leader, a Communication Manager, an Administration Manager, a Support & Documentation Manager, a Research Manager, etc. are mentioned, so I thought these roles might be relevant. The same group of people working on the same projects in two different ways, this is still a bit hard for me to grasp.
What, in practice, are the main tasks of the people managing the development?
There's nobody managing the development ;) We're auto-managed.
I see your point. So everyone (who is interested and dedicated) takes an equal part in making decisions? Do you think these collegial agreements would still hold if the base of contributors was significantly larger or wider spread, and therefore incorporated more diverse ideas about the project? Or would the system have to be adapted to scale successfully? Kind regards, Martin
On May 19, 2012, at 2:27 AM, Martin Schönberger wrote:
Thank you both, again, for your answers!
Hope it helps
Yes it definitely did, and could cast aside most of my uncertainties. I have just a few quick remarks and follow-ups:
In a related matter, many of the role descriptions of the core developers contain manager and leadership titles.
Hmm. Do you have a link? AFAIK we just have committers.
I'm sorry, I guess my mistake here was not taking the separation between XWiki SAS and XWiki.org into consideration. I was referring to http://www.xwiki.com/xwiki/bin/view/Company/Team, where three Project Managers, a Team Leader, a Communication Manager, an Administration Manager, a Support & Documentation Manager, a Research Manager, etc. are mentioned, so I thought these roles might be relevant. The same group of people working on the same projects in two different ways, this is still a bit hard for me to grasp.
It's easy: think about it in the same way in which a person always belongs to several groups: * group of your close friends * group of people sharing a hobby with you * group of people playing a sport with you * group of people going to Church with you etc For all these groups you're the same person but with different hats when you're in one of those groups. And each of these groups has its own rules. The only hard part here is that there's the word "XWiki" in both entities (open source project and company). I personally don't like this since it brings ambiguity when we have a very clear separation between both.
What, in practice, are the main tasks of the people managing the development?
There's nobody managing the development ;) We're auto-managed.
I see your point. So everyone (who is interested and dedicated) takes an equal part in making decisions?
Yes. That's our vote process.
Do you think these collegial agreements would still hold if the base of contributors was significantly larger or wider spread, and therefore incorporated more diverse ideas about the project? Or would the system have to be adapted to scale successfully?
Right now we're about 15 active committers. I have no idea at what level it would break but my gut feeling is that it would hold till about 50 active committers. The reason for this value is that I've worked in the past in company where we all had the same title and worked collegially and we only had to introduce a hierarchy when we reached 50 employees or so. Actually I even think that the open source project could go beyond this value since it's much more free and relaxed than a company. Note that I'm talking about committers. Now there are a lot more people participating in various ways (raising issues, suggesting ideas, supporting others on the list, writing articles/blog posts/tweeting, sending pull requests, etc). Also note that there aren't that many projects with 50 active committers (Actually I can't even cite one!) so we're pretty safe for a long time IMO ;) Thanks -Vincent
participants (3)
-
Guillaume Lerouge -
Martin Schönberger -
Vincent Massol