4 May
2012
4 May
'12
12:07 p.m.
On Thu, May 3, 2012 at 9:32 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com
wrote:
On Fri, Apr 20, 2012 at 9:43 PM, Martin Schönberger
<maschonber(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.
wrote:
2012/4/14 Vincent Massol
<vincent(a)massol.net>et>:
> Well I'm fine with both too but I really think you'll get more
extensive
result from asking on this thread:
we
* 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 don't always agree! (which is very fine)
various
* this interaction will be archived and
searchable in the future so
people won't just see the result but the whole
interaction and the answers from different people
Hi Martin,
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?
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
Yes, as Caty and Guillaume said, the more eyes are looking, the better the
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs