Planning for upcoming XWiki Days for 2024

Hi devs,

I feel it would be good to progress on XWiki Days other than just BFDs. However we still need the BFD.

Thus my proposal is to have an XWiki Day different than a BFD 1 week out of 3 for 2024 (and then we can assess and revise if we continue or not in 2025).

Here’s what it could look like (see the days definitions in XWiki Days):

  • 4th of July: Test Fixing Day
  • 11th of July: BFD
  • 18th of July: BFD
  • 25th of July: Improvements Closing Day Automation Improvement Day
  • 1st of August: BFD
  • 8th of August: BFD
  • 15th of August: Test Fixing Day
  • 22nd of August: BFD
  • 29th of August: BFD
  • 5th of September: Sonar Fixing Day Quality Fixing Day
  • 12th of September: BFD
  • 19th of September: BFD
  • 26th of September: Test Fixing Day
  • 3rd of October: BFD
  • 10th of October: BFD
  • 17th of October: Deprecation Fixing Day
  • 24th of October: BFD
  • 31st of October: BFD
  • 7th of November: Test Fixing Day
  • 14th of November: BFD
  • 21th of November: BFD
  • 28th of November: Doc Fixing Day
  • 5th of December: BFD
  • 12th of December: BFD
  • 19th of December: Test Fixing Day
  • 26th of December: BFD


  • The idea is to have the max of Test Fixing Day as I believe it’s the most important (to fix flickers/add missing tests, but also so that QA can mark more tests as automated and thus be able to test faster and focus on testing stuff that doesn’t have automated tests). Thus I’ve tried to put 2 “Test Fixing Day” and then in between try some new type of XWiki Day to discover them and see how they’d go.
  • I’ve not put PR Closing Day as I believe we need to do that all the time and it seems it’s happening.



+1 from me :+1:
It’s quite more complicated than BFD on Thursdays. I’ll probably create and share an .ics with the days for 2024 if this planning is agreed upon :slightly_smiling_face: .

Lucas C.

Hard to track (we should definitely have some shared calendar) but yes, would be nice to do other types of days.

I’m not convinced this one is very useful. I would rather insert something like a Build Optimization Day instead (analyze the build and try to reduce the time it takes to build and the memory it’s using).

Might be a bit too restrictive, what about a "Quality Fixing " instead, which would include various static analysis and -Pquality related stuff (fix some stuff reported by Sonar, make Checkstyle pass on currently ignored file, etc.).

Ideally this should include stuff like improving the test framework and migrate jmock/junit4 to current best practice.

I feel that this type of day is hard to parallelize and find something to do for everyone. But we could do this one which is a generalization: Build/release tooling days: improve build/release related scripts and tools especially automation or even better have an Automation Day to work on automating stuff that could be automated to win time during development (can be anything).

Sounds good to me.

Yes we could generalize, my fear is that we’re going to spend more time on topics others than implementing missing tests for maual test and fixing flickers, while this is what we would need the most.


Thanks for the replies. I’ve now:

1 Like