The document summarizes information about developing the XWiki software platform. It discusses XWiki's governance practices, development flow, code quality practices, testing practices, roadmap and release process, and how developers can contribute. Key details include XWiki being an open source wiki and web development platform since 2004, its meritocratic governance model, over 200 code contributors in the last year, over 9 commits per day, and ways for developers to get involved through JIRA, pull requests on GitHub, and creating projects on the XWiki contribution organization.
2. Agenda
● About XWiki
●
Governance Practices
●
Development Flow
●
Project Stats
●
Development Practices
● Code Quality
● Testing
●
Roadmap & Release
●
How to contribute
3. About XWiki
● Organize information collaboratively
●
eXtensible wiki & web development platform
●
CRUD API for structured data stored in wiki
pages
● Knowledge Base, Collaborative Intranet,
Documentation, Education
● Since 2004
●
LGPL 2.1 Open Source License
4. Meritocratic Governance
●
Committership, voting, lazy consensus
●
“5 +1, 2 +0, no -0, no -1, vote passed!”
●
xwiki.org governance and advertising
Source: dev.xwiki.org/xwiki/bin/view/Community/Governance
13. Code Quality
● Full wiki for shared practices on dev.xwiki.org
● Common code style (Checkstyle, Enforcer)
● Continuous code reviews
●
Backward compatibility (CLIRR) and
deprecation strategy
● XWiki special days
●
sonar.xwiki.org
15. Roadmap & Release Practices
● Complete Roadmap Process
●
Short releases (every 3-4 weeks)
●
Release Manager + Roster
● Release application on xwiki.org
●
Documentation fields in JIRA
16. How to Contribute
●
JIRA/mailing list/Spread
word/etc.
● Pull Requests on GitHub
●
extensions.xwiki.org
●
Create your project on
github.com/xwiki-contrib
●
And get a JIRA, wiki and
Maven repo
The XWiki project is governed by its committers. Committers are long standing contributors that watch over the project to ensure it goes in the right direction. All important decisions (regarding people, processes or code) are made with a vote, so in order to become a committer you have to be voted. All votes are equal and any committer can veto, but the vetoer must explain his decision and a debate is started. A vote is not required for minor changes or when the author thinks the rest will agree with them. We call this lazy consensus.
We had 25 code contributors in the last 12 months. Most of them are from Xwiki SAS, including myself. We're trying to attract more contributors, but it's not easy for an enterprise software.
Only 9% of the commits were made by people outside XWiki SAS. But they were important commits!
We had 205 pull requests created in the last 12 months. It's hard to filter those closed with a merge, but I can tell you that most of them were like this.
We host our code on GitHub in two organizations:
* xwiki: code that is maintained by the “XWiki Development Team” (active committers)
* xwiki-contrib: code that is maintained by individual developers (or code that is not maintained any more, retired)
In the last 12 months we had a small decrease in the number of commits (at least that's what Ohloh is showing) but we're still at 9.7 commits per day.
As you can see on the graph we had a steady number of commits per month since the beginning of the project.
We use JIRA for tracking issues and we're closed to 10k issues reported so far on the XWiki Platform.
In the last 12 months we have closed more issues than there were created.
100 users reported 3.8 issues per day, 56% of which were bugs. Still, most of the issues were reported by committers.
23 users have closed 4.25 issues per day, 67% as fixed.
We have multiple mailing lists but the main ones are users and devs, on which we had an average of almost 16 mails per day (cumulated) during the last 12 months.
We have a wiki dedicated to translations. It runs an XWiki app that allows us to import translation resource files (e.g. Application.properties). Registered users can translate the available keys afterwards. The XWiki API allows us to compute stats such as these.
We recently (5.2M2) introduced a component to track the number of XWiki instances. This component sends a ping daily to a configured server. It uses Java's UUID to identify the XWiki instance and the only information sent is the XWiki distribution id and version. As you can see we have around 800 active installs of XWiki 5.2M2+.