New strategy for XWiki days going forward

Development
#1

Hi devs,

Context:

  • We’re lacking a bit of steam for doing our BFDs that we’re still supposed to do every week. Currently, I feel that the devs are trying to push as much as possible on their roadmap stuff.
  • The result is that created bugs are winning again, see Loading... for more details:
    Screenshot 2023-12-08 at 13.54.40
  • It would be good to try to improve our quality further by working on our tests and SonarQube reports.

Proposal:

  • Reinstate official XWiki Days and create a momentum by making sure we ALL work on them during Thursdays (basically, the default will be that we all work together on them each Thursday and if there really is a reason making it not possible, ask to be excused on the #xwiki chat). I think the fact that we do this as a group makes the motivation higher.
  • Create a “XWiki Days” category on the forum to announce the next xwiki day one week in advance, allow discussions about it and publish the day’s results and close the thread as solved.
    • I’m happy to do the organization work for this, for some time.
  • Do a BFD once every 2 weeks
    • During a BFD the rule for each dev is to close as many bugs as possible, with at least 1 bug. Reminder for the new devs: the BFD is not about fixing bugs (as it name doesn’t imply ;)) but about closing bugs. This means that closing a bug as “cannot reproduce”, or “duplicate”, or “invalid”, or “won’t fix” counts. It’s actually recommended to close those as a priority in order to close a maximum during that day.
  • Every other week, do another type of XWiki Day. I’m proposing to start with 2 days that will help improve our quality:
    • Test Fixing Days (TFD). During this day all devs work on either:
      • Fix a flicker
      • Implement a Manual QA-requested-test. This is important because these, when fixed, allow Ilie to no longer run manually the test when testing the XWiki releases. That’s a big win in time across the years.
      • If the previous two are not possible (e.g. if they’ve all been fixed or are too hard with your knowledge, or …), add some new missing tests. They can be taken by checking the manual tests on tests.xwiki.org and implement those we miss.
    • SonarQube Fixing Day (SFD). During this day all devs work on reducing violations found by SonarQube for Commons, Rendering and Platform. Priority: Be graded A for all topics and have no “Bugs”.

We can decide to do other types of XWiki Day in the future but I propose we start with these 3.

To be clear, the idea is to do:

  • BFD
  • TFD
  • BFD
  • SFD
  • BFD
  • etc.

Note that one rationale for intermixing other xwiki days between BFD is to create some variations and keep the motivation. Ofc, it’s also to get other aspects of quality progress more.

I’m proposing that we start this next week on the 14th of December.

WDYT?

Thanks

PS: Reminder that when developers officially take topics for the roadmap, it’s recommended to fill only 50% of your time, in order to leave time to work on other stuff: refactorings, xwiki days, answering support questions, making proposals to improve the XWiki development or XWiki itself, etc.

1 Like
#2

+1

-0 I’m not sure to really see the value tbh and it’s taking some time to write it etc. Instead I think it’d be more interesting to only have a generic Jira dashboard that would gather the BFD data based on labels.

Well, I’m mixed on your proposal, mainly because almost 2 thursdays in a month are generally already spent trying to stabilize the CI for the release.
So for me we should only focus on BFD every week for a couple of month: then only if we’re seeing progression we could try to add other kind of XWiki days.

#3

I understand your hesitation. I think it’s important from a motivation POV and to have a place where we publish the results (we used to use the xwiki.org blog but I don’t think it’s interesting for non-devs). Right now we already use labels for bugfixingday and have them in various dashboard, yet nobody looks at them and it’s not making us motivated to help out. We have no idea how many bugs we closed on a given Thursday for example.

You’re right though that for TFD and SFD we will need labels too.

Globally I think it’s not too much work. If it happens to not work out, we could always drop it.

#4

I have the impression the visualization you’re using is misleading. Looking at the past 120 days gives a different impression and shows that we’re keeping up with new bugs and the most recent BFDs successfully reduced the number of bugs:

image

Regarding the different kind of XWiki days, what about just allowing them during BFD? Fixing a flicker is also fixing a bug. And we could simply count manual test migrations, too. For SonarQube it’s a bit different but we could say it is okay to create a bug for something reported there and fix it during BFD.

I think in particular for new developers, BFD can be challenging as they neither know which issues can be closed/have been implemented already nor can they implement a bug fix easily/recognize which bugs are easy to fix. Allowing to write new tests could be an alternative here.

Another kind of activity I would like to see is reviewing and merging pull requests. We have currently 90 open pull requests. Some of that can already be part of BFD according to the official definition as merging a PR can mean closing a bug but I think it would be good to also encourage just providing reviews, closing pull requests that aren’t needed anymore, or also reviewing and merging pull requests that are features.

Regarding the “don’t work on your roadmap”, that seems sometimes a bit weird. Like, for example, I would be allowed to fix a security vulnerability that is not on my roadmap but not the one on my roadmap that has a higher severity? I would be able to review and merge an accessibility pull request that is not on the roadmap but not one on the roadmap? Would I be allowed to fix a bug if I need that bug fix for something that is on the roadmap? What if we put something on the roadmap with a note that it will be done during BFD? Is this not allowed anymore?

I’m +1 for more BFD but to me it seems the rules are a bit strict.

#5

+1 to for the general idea (i.e., BFD every Thursday)

Having a weekly report or a a dedicated label did not have an impact on my motivation. But ymmv, so I’m not against it if I don’t have to deal with the paperwork :wink:

+1 for thematic fix day on other aspect than bug themselves. Even though I always considered the other categories as in the scope of BFD, it’s difficult to focus on them in practice.

WDYT of Doc Fixing Day, where we look at how to improve some doc?

#6

While I agree that making the Quality Days in general a bit more mandatory (and more importantly, making sure it’s taken into account by all devs when designing the roadmap) would help, so +1 for that, I really don’t think the reports we used to do ever did, honestly.

That’s indeed a good point, and maybe something like Wednesday would be better (not suggesting Monday since it’s usually where releases happen or Tuesday since it’s when late releases happen :slight_smile: ).

#7

Yes this is true for the past 120 days as of today, but not on a longer period. To get the big picture you need to look at the various timeframes on: Loading...

What’s sure is that today, we are currently lagging by: 10062 - 9046 = 1016 bugs, and if you check the accruing rate, you’ll see that since 2014 it’s basically going up more and more:

Screenshot 2023-12-08 at 15.04.50

FYI in the past we had set a challenge to close as many bugs as there were created for the past 1000 days and then later for the past 1600 days. AFAIR we succeeded for 1500 or 1600 days.

For example in 2013, see [xwiki-devs] [Reminder] BFD#39 we were at -42 for 1500 days. Today we’re at -611.

#8

If you want to check all the ideas, they’re listed here:
XWiki Days - XWiki :slight_smile:

Now I don’t think Doc Fixing Day is the most urgent ATM on the quality side but YMMV.

#9

Well, BFD is BFD, it’s a special XWiki Day dedicated to bug closing, so the other days are no considered during BFD. It’s a team effort to reduce the bug count on that day.

#10

For flickers, sure, that can be part of BFD since it’s a bug. But note that BFD is again not about fixing bugs but about closing the maximum of them. So picking a flicker is bad idea for that day as you probably won’t be able to do many (since flickers are hard to fix). You need to pick low-hanging fruits on that day.

For Sonar and others, the idea of BFD is not to create new bugs and close them :slight_smile: So it would be a bad idea for that day. Also, having devs focus on different stuff on that day is not a good idea to make progress together on a given topic IMO. I’m skeptical that it would work to not be focused on that day. I mean it’s better than nothing for sure, but less good than a directed day IMO.

BFD is not about fixing bugs. Finding dups, cannot reproduce, invalid, etc is not too hard. TBH we’ve been doing this for years and it’s always worked when we were doing it actively. It’s just that for the past few years we’ve left it be optional and no longer did it all together. Back in the days we were closing like 20+ bugs every Thursday.

BFD is basically about bug triaging + fixing very simple ones (low-hanging fruits).

Yes, we have a XWiki Day for that too, see XWiki Days - XWiki and XWiki Days - XWiki

We haven’t done it often though. It’s more complex than most other XWiki Days though.

Again, the point of BFD is to work on stuff we don’t do as part of our roadmap. So triaging bugs + fixing low-hanging bugs. If you use the BFD to work on your roadmap then it won’t help much. Also, you probably won’t be able to close so many bugs. Note that this has always been the definition of BFDs, even today. I’m not suggesting any change on this. Ofc, we’re not strict, but the idea is about the quantity on that day.

Thanks

#11

Yes, we could move the day. On Wednesdays, I’m in meetings most of the day but it probably doesn’t matter much and would be hard to find the perfect day. Tuesdays would be fine for me too. However, sometimes we delay the release to Tuesdays though and on release day we must not do BFDs for sure :wink:

I think it should still be ok to have XWiki Days on Thursdays even if we also start stabilizing the build on the side (it’s usually not a full day job for all devs). It just means that on those Thursdays, the XWiki Day will have less done. For BFDs, we should still be able to close 1 issue on those Thursdays (some dups, won’t fix, etc).

Now I’m also fine to move to Wednesdays if we all think it’s better.