Hello Vincent, Thank you for your swift response! I took my time and re-read the developer-section of XWiki in its entirety, and I have to admit the data provided there is quite extensive. But then again, this was one of the reasons this project caught my eye in the first place. Maybe my wording was a bit unfortunate when I described the topics I'd like to discuss. In using the available information about the process as a basis, I would like to go deeper with my questions, talking about background, personal experience, exceptions and the development of the process over time. In the case of XWiki, I'd also be particularly interested in the relationship between the Open Source development methods advocated on xwiki.org and the corporate structure of XWiki SAS. I chose the method of semi-structured qualitative interviews instead of a standardized survey or the analysis of available data because it is responsive, adaptable and allows for immediate feedback - and I'm a bit hesitant of spamming the developer mailing list with a series of questions and follow-ups. That's why I suggested a one-on-one talk - I did not intend any secrecy, and would of course disseminate the outcome of the conversation back to the community. But either way works for me. If you are (or anyone else is) still willing to answer my questions, I can also ask them here in this thread, if you prefer so. Kind regards, Martin

2012/4/14 Vincent Massol <vincent(a)massol.net>et>: Well, consider me convinced. :) Let's try this the open source way then! Everyone is very welcome to join in on the conversation. As Vincent suggested I am going to split up my questions into three or four posts, roughly separated by topic. This first post contains rather general questions about the process and the stages of development, while the follow-up posts concentrate more on the project's management, people, structure and infrastructure. You can assume that I am aware of the development process as far as it is detailed on dev.xwiki.org and xwiki.com, and for my research I would like deepen this knowledge, especially on how the process is applied in practice, and how it is seen from within. So, without further ado, my first questions: As far as the process is concerned directly, which are the parts of development that profit most from the fact that XWiki is open source? It seems like XWiki has a rather large core team closely working together, and the Hall of Fame lists rather few external contributors. Does this reflect the actual distribution in the project? What are the costs and benefits of using open source development methods in this situation? Would communication patterns, knowledge management and development cycles be approached differently if XWiki was developed purely in-house? Another thing I'm interested in is how the scope of the project and the direction of development are decided on. To what degree do different stakeholders influence the course of XWiki, what is caused by personal itches of the developers, requests of paying customers, or complaints and suggestions of casual users? Is there a special time in the release cycle when new content is agreed upon? How far and in what detail can the content of future releases be planned ahead by the developers? Are detailed plans desirable, or is it more advantageous to react to circumstances when they arise? The third question concerns specialized tasks surrounding the development. XWiki follows diverse strategies for testing. One of them is manual, formal testing executed by a dedicated QA team. Does this part of the approach make the many-eyeballs-method of discovering bugs less important, or is a combination of these two strategies necessary for overall high quality of the code? Could automated testing stand on its with sufficient coverage? On a similar note, how do the different methods pursued in customer support (like detailed documentation, peers helping each other, and specialized paid support) interact and draw upon each other? I phrased the questions deliberately at length to roughly stake out the areas I would be more interested in. Every comment, opinion or experience that relates to the given topics is highly welcome. I will eagerly keep track of the mailing list for answers and follow up with the next round of my questions in a few days. Kind regards, Martin

On Thu, May 3, 2012 at 9:32 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com Quality of the product is. I am the QA responsible of testing XE and XEM, but a lot of other bugs are reported by the community. We have a formal Manual Test Plan, you can check http://www.xwiki.org/xwiki/bin/view/TestReports/WebHome . Besides this, we have also an automated tests suite maintained by tech team. We don't have a dedicated team for Testing Automation. For example, there are certain things I always look for, for example: cross-browser compatibility, database migration, etc. The role of the community is important because we have a lot of extensions or use cases which we don't have time/resources to test, but the users which installs them write on the mailing lists, report issues or even provide patches if they find bugs. Usually when a user from mailing lists has troubles accomplishing what he/she wants, we check if that is a valid use case, our developers being very responsive in aiding them. If the use case is valid, this usually goes documented in the according place, so other users wanting to do that, won't have to write on the lists. So the QA is done collaboratively, not only by a dedicated team or individual. Hope this helps. Regards, Sorin B.

Hi Martin, Sorry for having taken so long to answer. We have a lot of holidays in France in May. I flagged your message as important then took some holidays, forgot about it, then other holidays and now I'm back! Disclaimer: I have 2 hats: * one as an xwiki committer like any other * another one as the CTO of XWiki SAS (http://xwiki.com) See below. On Apr 20, 2012, at 8:43 PM, Martin Schönberger wrote: Obviously it's hard to contribute to the core of an open source project than it is to contribute to extensions/plugins. This is the case with XWiki. Actually what we've started doing a few years ago and this is still underway is to split the monolithic XWiki code into small modules, each implemented a specific feature (tag, querying, wysiwyg editor, rendering, etc). We have hundreds of such small modules which makes it easier to contribute than before. In addition we've started to make all those modules extensions, i.e. features that can be added/removed from an XWiki runtime. And we now have an Extension Manager in the XWiki runtime to manage all extensions. This means that when someone contributes an extension on extensions.xwiki.org it's directly visible from within everyone's installed XWiki runtime, in exactly the same way as extensions created by the XWiki Dev Team. Thus I believe we'll continue to see more and more contribution in the area of extensions. We have several layers of code contribution: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing#HContributeCode Note: I've updated http://dev.xwiki.org/xwiki/bin/view/Community/Contributing this morning Now more generally the XWiki open source project benefits from: * extensions * testing by the community and bug reporting * discussions on the mailing lists to give ideas, to direct our work The list is valid for the committers. We're about 15 active committers (ie. XWiki Dev Team). We've always had a hard time identifying contributions since there are lots of ways to contribute. Thus we asked contributors to add their names to the Hall of Fame page but lots of people are shy or simply don't think about putting their names there. We've now moved to GitHub and it's much easier to recognize code contributions since we now use pull requests. I'm preparing a new section for the hall of fame that'll list all code contributors (and not only committers). Definitely. One important difference is that there's no power hierarchy in XWiki development. All the committers are equal. We have built our rules on the Apache model which is a Meritocracy. See http://dev.xwiki.org/xwiki/bin/view/Community/Committership and especially our vote strategy. It's enough that a single person doesn't agree for something to not happen. The strategy: * In the open source project, there are only individuals, no company. At the start of each release committers and contributors can state what they'd like to work on for this release. We publish this on our roadmap page: http://www.xwiki.org/xwiki/bin/view/Main/Roadmap (specialment http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap pour XE). * At XWiki SAS, we do internal roadmap meetings and then find/assign developers who're going to be the owners of issues/features on the xwiki open source project. During these internal meetings we have representants of all XWiki SAS domains (marketing, customer project, sales, tech, research, infrastructure, etc) present and decide in a collegial manner. Actually we don't have any notion of QA team in the xwiki open source project. At the open source level each developer is responsible for the quality of his code and is supposed to write automated tests and do manual testing of his code. However we have one contributor named Sorin Burjan who's helping the developers do this by systematically testing new releases himself. He's helping us a lot. But he's acting as a contributor. Now Sorin is also an employee of XWiki SAS and within XWiki SAS his role is QA engineer and his internal role is to make sure that releases are of good quality. Combination. I'd say the vast majority of issues are still reported by the many eyeballs. But Sorin finds a good lot too! :) Both are needed. IMO it could but we haven't reached a good enough level yet. We need to become better at this and start measuring better our test coverage. We have just started automating tests on various environments (DBs, browsers) and that'll take some time. In the meantime Sorin has taken charge of manually testing XWiki on those various environments. At some point we'll also need to add automated performance tests which is done manually too at this point. XWiki SAS internal support will raise issues in our issue tracker like anyone else and these will get fixed eventually. In general the most people who report an issue and faster the XWiki Dev Team spends time on fixing it quickly. Thanks, hope it helps -Vincent