4 May
2012
4 May
'12
11:45 a.m.
Hi Martin,
here's my reply as well. Please see my answers below.
On Fri, Apr 20, 2012 at 8:43 PM, Martin Schönberger <maschonber(a)gmail.com>wrote;wrote:
2012/4/14 Vincent Massol <vincent(a)massol.net>et>:
We get plenty of testing of all parts of XWiki from plenty of people, some
of whom contribute specific fixes that would otherwise not be worked on.
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.
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?
Yes and no. Sure, most full-time XWiki developers are paid by XWiki SAS,
but it's also because the company went to hire active community members.
There are also some former employees who are still contributors although no
longer employed by XWiki SAS.
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?
Not really. The same processes would be used, only limited to internal
mailing lists.
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?
All of those factors play a role. Some customers pay for the development of
very specific features or extensions. For instance, the Office document
Import feature was paid for by a client.
There is an internal roadmap process at XWiki SAS where stakeholders from
every department can voice their priorities (sysadmin, dev, project
management, sales, marketing, research...). Once this has been done, a
roadmap is proposed, that members of the Open-Source community can add to
if they wish.
In addition to this, about 40-50% of the time of core developers is
preserved so that they work on maintenance and bug fixing tasks, which they
choose what to spend on.
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?
Given the very frequent release cycle, meetings take place often. There is
a new large release every year, interspersed by major releases every 2-3
months. There is a roadmap meeting for each of those, thus it's easy to
gather feedback and make priorities evolve along the way. For a large
release, a theme and a sub-theme are agreed on that set the general
direction of that release. For major releases, a list of JIRA tasks is
agreed on.
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?
Open-Source users tests parts of the software not tested by the QA team,
and vice-versa. Both methods complement each other.
Could automated testing stand on its with sufficient
coverage?
No. Some things cannot be tested automatically, especially on the look &
feel side.
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?
Documentation is updated based on the most frequent requests from
customers. Paid support users are usually different from mailing list
users, although some of the latter do convert to the former from time to
time.
Guillaume
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs