Proposal for updating the "Powered by XWiki" section on the xwiki.org homepage

Hello!

I’d like to propose an update to the “Powered by XWiki” section on the homepage of xwiki.org. Under “Powered by XWiki”, I’m noticing that projects from many years ago are sometimes listed (example below with vCalc).

My proposal is to update the macro so that it shows project from the last 3-5 years maximum. The “Powered by XWiki” should stay the same and send to the references pages, but the references themselves that appear on the homepage should be more recent and relevant to how XWiki has evolved.

Let me know your thoughts on this. Thank you!

We could but I’m not sure we want to do it:

  • On one hand, it’s true that we say it’s “xwiki powered” web sites but they may not be powered by xwiki anymore. However, you can have a reference of 1 year ago and yet XWiki is no longer used there.
  • On the other hand, if you want to see what you could do with XWiki by seeing what usages were done then it’s nice to see all the references.

Thus for me we really have 2 solutions:

Solution 1: Changing the section title from “Powered by XWiki” to something else, like “Usages of XWiki”. And then we can display any reference, even old ones.

Solution 2: Have another xproperty in the references xclass to indicate if the reference is still active or not. This was discussed in some other thread after someone found that clicking the website link doesn’t work any more. So we would update each reference one by one when they don’t work. Then the “Powered by XWiki” section will only take from the active list.

Thx

I think solution 2 would work well and be quite time efficient :+1:

In addition to solution 2, we might want to add the year of creation in the card.

By adding this date, if an old project pops up, it’s easy for users to understand that it might not run on the latest version of XWiki. From my point of view it’d be easier for them to understand that the project might run on an old version of XWiki.

E.g. Regarding accessibility, I’m pretty sure that it wouldn’t be a very good first impression of our tool if a blind user checks out vCalc and assumes that’s what the state of accessibility would be if they start using XWiki :

This way we can use our old references as a way to show potential new users that XWiki projects can stand the test of time and reduce the chance of giving wrong ideas.

Thanks for bringing that up!
Lucas C.

So, if I understand correctly, someone needs to check each project and update the parameter with Active? The issue I see here is with users or organizations that use XWiki internally, and we don’t know if they actually still use XWiki.

In addition to solution 2, we might want to add the year of creation in the card.

This is a good idea!

It’s not about knowing if they still use XWiki but about whether the website URL is still working (and ideally points to an XWiki instance if that can be found, if not then we consider it’s active until we’re told it’s not the case).

Also it wouldn’t be done by someone on all, the community would help. For ex, recently we had someone who told us on the forum that for such reference the website URL was not working anymore.

I’m not sure the criteria with the website URL can be applied since for adding the website URL someone must enter in objects to update this. Examples of users adding references but not adding any website: 1, 2, 3.

The website is a clear indication if it stops working. Of course, it’s not the only one and if someone from the community knows for a fact that the XWiki instance from a given reference is no longer active then they can either mention it on the forum or mark it as inactive. The best ofc is get this information from the “contact” information or from the creator of the reference (usually someone involved with the project).

In any case, I feel that this “active” xproperty is the best we can do and is better than using the age which doesn’t say anything about the usage of XWiki (and it also provides more information to us).

i’m fine with adding the year but IMO it doesn’t say anything about the version of XWiki it might be running nowadays. Or maybe you meant the version of XWiki when the screenshot was taken?

It’s like saying that reading some code in java which has bugs will lead to you considering java a bad language :wink: It just says that either the user didn’t pay attention to this aspect or the XWiki version used in the screenshot was not WCAG compliant. But if a user wants to see how XWiki looks, the reference section is clearly not the right place… they should check the XWiki documentation and screenshots, that seems quite obvious, no?

The point of the reference section is to give ideas and show what users are doing with XWiki! And to show how versatile and customizable XWiki is. This can also be seen on the Skin page, in the examples: https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Skins#HExamples (this is taken dynamically from references).

So far I see that both Lucas and myself are agreeing about it, and unless @DorinaAnton is against it, I can implement it (it’s quite easy).

Thx

I can agree with the proposal if the website property would appear by default also in the newly created page as opposed to a user having to:

  1. Create a new entry for their reference
  2. Complete some info and save the page
  3. Enter in objects to find the website field and complete it

This is what appears when someone creates a reference for the first time (no website field):

That’s clearly a bug. Checking

It got broken at https://www.xwiki.org/xwiki/bin/view/XWiki/ReferenceSheet?viewer=changes&rev1=43.1&rev2=43.2&

Fixing.

Fixed, this means we have been missing these pieces of information since 2017… :frowning:

I’ve found that we’ve tried to tackle this problem back in 2016 :slight_smile:

See https://www.mail-archive.com/devs@xwiki.org/msg31983.html

Especially this part:

  1. References: currently we are randomly selecting from the whole list of
    available references. Ideally we should provide a shorter list containing
    high quality entries of websites build on top of XWiki.

As a consequence, it seems that I have added a “recommended” xproperty to the ReferenceClass at https://www.xwiki.org/xwiki/bin/view/XWiki/ReferenceClass?viewer=changes&rev1=9.4&rev2=9.6&

I’ve also checked if we’ve used it and it seems we did for a while:

{{velocity}}
#foreach ($entry in $services.query.xwql("where doc.object(XWiki.ReferenceClass).recommended = 1").execute())
  * $entry
#end
{{/velocity}}

Yields:

References.WikiTerritorial
References.AFCEN
References.SFR Altice
References.Lenovo
References.ObjectWeb
References.CdLSWorld
References.Energisa
References.Springer
References.Brabantia
References.vCalc
References.INRA
References.The Historical Dictionary of Switzerland (HLS)
References.The Karlsruhe Institute of Technology
References.OSI-Wiki
References.CNFPT
References.KEN
References.Amazon
References.FNAB
References.EasyVista
References.USH

The “Powered By” section is using a wiki macro that IS picking references from the recommended list :slight_smile:

In https://www.xwiki.org/xwiki/bin/view/XWikiOrgCode/PoweredBy the {{poweredBy}} macro is using:

[...]
#set($referencesList = $services.query.xwql("where doc.object(XWiki.ReferenceClass).recommended = 1").execute())
#if($referencesList.size() > 0)
[...]

So this whole thread shows that the recommended strategy (white list strategy) doesn’t really work and since 2017 we keep showing only a small number of references and old ones (I see some new ones in the list but globally it’s old ones), defeating the whole purpose of the recommended strategy…

My belief is that this white liste strategy is too costly in maintenance, and we need a new one. I prefer the black list approach of the active xproperty because:

  1. It doesn’t require any maintenance when new references are added and thus we’re showing a greater diversity of references to the users on the home page
  2. It still allows to block showing references for companies not using XWiki anymore or “bad” references (whatever this means)

Of course, it means that we could show “old” screenshots of XWiki but that is partially offset by the display of the date as mentioned by Lucas. I guess that date would be the year of the 1st attachment displayed.

WDYT?

If they had a block of buggy code on https://www.java.com/en/ , I’d assume java is a bad language. Their documentation would highlight some code that doesn’t work, meaning that either the project maintainers don’t care about documentation or about code correctness, which are both pretty bad things to ignore for a programming language. Note that Java is quite widely known, so this page is rarely a “first impression” for people. I expect xwiki.org to be the “first impression” of XWiki for a lot of people, keeping this first experience polished (at least concerning the points we actually care about) will avoid losing potential contributors.


Sounds good to me :+1:
Thank you for looking into it!

I disagree :slight_smile: We’re not talking about any official content here but examples of content or code contributed by users.

The XWiki core developers (as maintainers of the xwiki.org web site) are NOT validating references which are contributed by users of XWiki. They don’t validate the reference examples for:

  • Whether it’s a valid usage of XWiki or not
  • Whether the skin they did is nice or not, following best practices or not, including WCAG
  • Whether what they did is performant or not
  • Whether they’re using the latest versions of XWiki only
  • etc.

If it’s not clear that this section is about examples of people using XWiki then we need to make that clear. But for me the “Powered by XWiki” meant that. If it’s not clear we can put some disclaimer on https://www.xwiki.org/xwiki/bin/view/References/ just above the list of references but it seems quite obvious to me and if we can do without, it’s better, as it would pollute a bit the page.

And re the java website, you can definitely not compare it as they don’t provide a way for anyone to promote example of their java code…

Anyway this is just for the sake of the discussion since we seem to agree about the solution :wink:

Thanks for your input. Would be good to see if some other committers agree with the “active” + date proposal.

1 Like

I agree with the black list strategy as it’s easier to do (filter out the expired wikis rather than mark all active ones).

I also agree with having the year in the cards.

Does anyone else have an opinion about Vincent’s solutions so that an agreement is reached about the proposed improvements?

Thank you!

I’d like to come back on this topic and ask how it is proceeded when a topic doesn’t get +1 or -1 on the forum?

Thanks!

I didn’t write it explicitely but here’s my +1 for the blacklist implementation and using date.

In general votes should be sent in case of big changes (whether it’s about code or about processes or people). A vote is mandatory for voting in new committers or from removing committers. It’s not necessary to send a vote when performing minor or even sometimes substantial modifications provided the author judges everyone would agree to them. This is called lazy consensus. However should someone objects to the code committed, the author must then be prepared to revert it if asked.

from https://dev.xwiki.org/xwiki/bin/view/Community/Committership

In a few words, we VOTE for important community decisions (with clear rules detailed on the page), and we can use PROPOSALs for less important decisions. Proposals do not have to follow the same rules as votes (even if we often do use the same +1/-1 convention because it’s clear and convenient). As far as I understand it, the main point of a proposal is to avoid having a committer ask to revert your changes after you spent time on making it.

As far as I can see, people that participated on this proposal all agreed on a solution, and the topic did not sparkle a large debate (we pretty much all agreed from the start, even if we discussed implementation details). If I was responsible for the proposal I’d either:

  • Ask for more opinion and leave a bit more time to answer
  • Consider the topic is solved, it’s very unlikely anyone will strongly go against what was discussed here, and start applying the proposal.

__
I hope this explanation makes things a bit clearer. I’ll try to look where this explanation would fit in the doc because it looks a lot like some unwritten community governance practice.

Have a good end of the day!
Lucas C.