On Fri, Apr 20, 2012 at 9:43 PM, Martin Schönberger <[email protected]>wrote:
> 2012/4/14 Vincent Massol <[email protected]>: > > Well I'm fine with both too but I really think you'll get more extensive > result from asking on this thread: > > * you'll get the sum of our knowledge. There isn't a single person who > knows it all here. We all have some knowledge of some part of XWiki and we > don't always agree! (which is very fine) > > * this interaction will be archived and searchable in the future so > people won't just see the result but the whole interaction and the various > answers from different people > > > > So I'm all for doing it here :) > > > 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. > > Hi Martin, > > 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? > Regarding this topic there is also a blog series written by Ludovic where you can find some of the answers from the company perspective http://www.xwiki.com/xwiki/bin/view/Blog/XWikiVisionOpenSource > 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? > Regarding the other questions all that I can say is that I would love to have much more external contributors. Some of us start as independent contributors and get into the company, others work for companies related to XWiki and give back to the community in a form or another (tests, bug reports, improvements requests, community feedback and help, translations, documentation, etc.) The Hall of Fame reflect just long time participants, but the sum of all contributions should be made with all the users from l10n.xwiki.org; jira.xwiki.org; github.com/xwiki; xwiki.org, etc. In my case, first I contributed to XWiki as a GSOC student and after that period I was offered a position inside the company. And I am not the only case, same happend for other GSOC students like Eduard, Ana-Maria, Asiri, Sergiu, etc. So IMO getting from an external contributor to an internal one is great. >From my perspective (as an Interaction Designer) is great that I can work in an open source environment. I get to receive issues (bugs) reports from all over the world, I can ask our users what improvements they would like to see and what they think of my proposals. Sometimes is very hard to make everyone happy, but since I am the only one in the company that is responsible with this topic, if we didn't have this open environment it would be impossible to do my work: being in a remote team and being without a way to reach the users and learn what they need, I couldn't know what to do. Also, being in the open I can reference my work and get critics on it (and I would love an even bigger community so that I could learn even more things). > > 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? > Our development is made in release cycles. We do one cycle per year (for example we are now developing the 4.x cycle and we just released 4.0, so now we work on 4.1, etc.) In one year we get to have about 6 major releases per cycle (4.0-4.5). For each major release we have a Roadmap meeting, before the release starts, where we decide on what we work on. Check out http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap For each roadmap we vote on the mailing list the issues we work on, the release dates, we vote if we need to delay a bit the release because of certain problems, etc. So the decisions are transparent and everyone can give their opinion on them and interfere. A very-very important aspect is that we do timeboxing releases instead of feature-driven releases so this IMO is a big differentiator between being an open source company and a closed source one (and wait indefinitely for a certain feature). Read more about at http://xwiki.markmail.org/thread/s5wajg23uhqmtnyh Another important aspect is that even if we are a company, we have very clear departments. We have a clear difference between who is working with our paying customers (Clients Team) and who is working for the platform (Tech Team). So even if we collaborate inside the departments we have different purposes and different stakeholders. For the Tech Team the most important stakeholder is the community. Of course we care about what the Clients Team asks, but IMO we consider them as part of the community and as XWiki users (the only difference is that maybe their complains reach faster since this complains can be made in person). > > 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? > > Regarding this question, I just want to say that we are a small team. We have just a single person as a dedicated QA so all the help he can get is welcomed. For example, I test and report a lot of issues/improvements even though I am not part of the QA team. Another thing is that XWiki is multi OS, multi browser, multi database, multi display, multi whatever compatible :) We always need more eyes, hands, automated tests, manual tests, any kind of tests to verify the quality and then ... we always need more committers to fix them. Hope this helps, Caty > > 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 > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
