10 May
2012
10 May
'12
8:28 p.m.
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#HBackwar…
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