Thanks, this is indeed what I had in mind for a final version.
Do you think we need to make a proposal before marking as done in https://dev.xwiki.org/xwiki/bin/view/Drafts/SustainabilityBestPractices/ ?
Yes, I think it would be good to have validation by all committers. But we can ask for several pages at once (when we think theyâre ready), to avoid asking too often.
For now Iâve put âReady for validationâ as status for that page.
1 Like
If you want to have my comment on this, I have the feeling sustainability is simply a re-labeling of things we should already be doing. There is accessibility, which is already something weâre doing, there is protection of personal data, which is also something weâre doing (maybe we should do more), and then I believe the remaining part is basically performance. I believe that the impact of the whole development process is tiny compared to the impact of the final product, so we should focus on the final product (consider 10 development machines + 10 CI VMs vs. thousands of production instances). And there I believe that most sustainability metrics are basically equal to performance:
- Reduce server-side resource usage (memory/compute requirements) by making XWiki faster (by reducing the actual compute, not just by parallelization) and making sure we donât use more memory than required. This should be measurable by server-side profiling as basically all resource usage impacts the performance.
- Reduce client-side resource usage by avoiding client-side compute, e.g., prefer static HTML that is cached server-side over client-side rendering which needs to be re-done on every client (so the opposite of what Cristal is doing I fear), and avoid frequent re-rendering (so no async or other kinds of lazy loading that impact the UI, make sure we specify all image dimensions, âŚ). There are also certain CSS styles that lead to higher resource usage, e.g., during scrolling I think. All of this should be measurable with client-side profiling as all of this impacts the performance.
- Reduce network transfer, e.g., by reducing the number of style sheets and JavaScript files (so their compression is more efficient and there is less request overhead), making sure that all images have the appropriate sizes, and ensuring that client-side caching is enabled for all resources. Again, network transfers can be measured with client-side profiling and directly impact the performance.
So, basically, I think sustainability best practices are almost equal to performance best practices unless you utilize massive parallelism, which we currently donât really do. So Iâm not convinced we should duplicate everything that we should already be doing for good performance under the sustainability label, particularly as a) performance is much easier to measure (itâs much harder to directly attribute CO2 emissions to a certain line of code, but it is easy to attribute running time to a certain line of code, and running time should be a good-enough proxy for CO2 emissions) and b) we might have the same guidelines twice in the end, once for performance and once for sustainability.
To summarize, I donât see the point of having the same old things we should already be doing under a new label. But if you want to put effort into this, I wonât stop you.
[Edit] There is of course one aspect that I forgot, which is marketing, being sustainable is of course nice for marketing purposes as everybody wants to use sustainable software.
The point is to simply check if we are indeed covering the sustainability guidelines.
We already comply with some guidelines for sure, but we probably donât do some others.
The examples you give are valid, and are covered by the sustainability guidelines.
But, thatâs not all of it.
And, regarding performance, we are not monitoring it in practice. Which is a miss for performance alone, if not for sustainability.
No, because if we already have an existing guideline weâll just keep it and mark the sustainability guidelines as completed by another rule.
If we get lucky, the only work will be to check the rules one by one and to realize that we are already doing everything 
We need to be careful there, sustainability marketing can quickly turn into greenwashing.
I think sustainability is a difficult topic.
I deeply care about reducing our environmental impact, itâs something which has basically always been part of my life in some way, and Iâm willing to accept at least some downsides of doing so, like travelling for 25 hours by train instead of flying.
Unfortunately, in many cases it isnât obvious what we should be doing to have the most impact. For example, instead of having this discussion, I could be working on improving XWikiâs performance - which of the two has more impact in reducing XWikiâs environmental impact? A guideline could have an impact through influencing others, but it could also have no impact and just distract me and others from actually reducing XWikiâs impact. Using LLMs, e.g., in software development, first increases emissions, just as using a powerful IDE instead of a simple text editor does - but in the end, the total emissions of me using an LLM a few times during an hour could also cause fewer emissions in total than me needing five times as long with a less powerful setup (that still doesnât have zero emissions, and you also need to consider the heating of the room Iâm sitting in for example). And this doesnât even take into account other factors, like that a less powerful IDE could lead to more errors and thus more follow-up work, or less productivity, which could mean that developers for example might not find the time to work on tasks that would reduce the environmental impact (but it could also be that developers wouldnât find the time to work on features that increase the environmental impact, as I said, itâs difficult to know the impact).
Even more problems exist in design decisions for XWiki, where I think if we wanted to reduce XWikiâs environmental impact to the minimum, we would reduce usability. Consider for example filters in Live Data or the quick search, where filtering is applied as soon as the user types - it would certainly reduce the environmental impact if the filtering or the quick search was only executed when the user confirms the input as it would replace several searches by one. However, I donât think we would want to do this as this would certainly reduce the usability.
Therefore, to me the best we can do is to:
- Ensure that XWiki provides great usability (which includes great performance both on server- and client-side, but may also include features that increase usability at the cost of additional resource usage).
- Make sure that we donât implement features whose resource usage is totally unreasonable compared to the value it provides.
I donât think it is possible to put this into formal guidelines. We can certainly create a mission statement to state that we care about sustainability, but I think in the end in many cases it will be a balance between usability and resource usage. What I could imagine as a concrete action is to ask for every change we perform to think about the environmental impact. What I imagine is a checklist of best practices, e.g., in our pull request template:
What impact does this change have on:
- the environmental impact/the resource usage of XWiki?
- performance (both server- and client-side)?
- security?
- usability?
- privacy?
- accessibility?
The idea of this checklist would basically be to make sure we always think about these criteria. The idea wouldnât be to reject changes that have a negative impact, just to encourage developers to think about these categories as even just thinking about them can have a big impact as we might notice flaws or alternatives that are better in these categories.
Interestingly, I discussed with @CharpentierLucas about proposing Make sure PR writers have thought about transverse topics
1 Like
I agree, but having a list of guidelines with factual validation make sure that we donât miss interesting aspects.
Also, the guidelines are categorized by potential impact and effort, helping us converge toward the most impactful actions first.
+1 given itâs really low effort to put in place.
Iâm not sure itâs easy to quantify the value a feature would provide. Features we want to implement in XS should be valuable for all use cases (else theyâd be in an extension). However some features will be very valuable in some use cases and barely provide anything in others. IMO if we want to implement a resource costly feature in XS, we should provide an easy way for admins to disable it.