What's New Feature in XS

Development
#1

Hi devs,

I’d like to propose a What’s New feature in XWiki so that our users can get news around the XWiki ecosystem directly in their instances (very muck like the same feature in gitlab, What's new | GitLab ).

I’ve created a design page where I have listed the requirements and some ideas for the implementation.

See What's New Feature (Proposal.WhatsNewFeature) - XWiki

Let me know (the vote is only about this, the other design items can be discussed as a proposal but I’m not asking a vote about them):

  • If you’re ok to add this feature to XS and have it bundled by default

  • If you’re ok with modifying the Governance rules slightly to add that the top sponsoring company (TSC) is allowed to provide its news source by default in XS, provided that the news in it are globally interesting to the XWiki community and presented in a nice community-oriented way.

    • XWiki SAS would be interested to add a news source for their paid apps by default. We already have XWiki SAS’s paid extension repository added by default.

    • Related entries in the Governance page:

    • Allow Sponsoring companies creating XWiki to publish blog entries to present new offers/services/extensions. Since we don’t want this to turn into spam, the rule is no more than 1 such blog entry/mail per month to start with and those entries must to be presented in a nice community-oriented way.
    • Allow the Top Sponsoring company to create a monthly newsletter sent to the users list, gathering news about the xwiki ecosystem in general (product news, events, new offers/services/paying extensions, tips, etc). There could also be surveys. The Top Sponsoring company is encouraged to gather such news from other sponsoring companies to include them in the newsletter. The idea is to let the community be more aware of all news that exists be them free or for pay, and in addition also advertise conferences at which xwiki is represented, etc.
    • Allow displaying the xwiki.org blog in the XWiki runtime.
    • Sponsoring Companies can have their own extension repository defined in the default XWiki configuration (in xwiki.properties). To qualify, a Sponsoring Company must have at least 3 active committers to be able to have their stores listed by default in the XWiki config. The same is true for nexus.xwiki.org.

Here’s my +1 for both questions.

Thank you.

Operating the What's New feature
#2

+1

+1 as long as user are able to opt-out of a given source.

#3

Yes, this is UC3 (full opt-out) and UC100 (selective opt-in/opt-out from sources).

#4

+1

I’m +1 only if we have the opt-out feature allowing admin to disable it. By reading the design page I think it would be:

UC100: Allow admins to choose the news sources to display in the wiki

I’d be -1 to have it if it’s not easy to disable, I see that you plan to have possibility to disable entirely the feature, but sounds a bit extreme for only removing a single source.

#5

It’s just that for the MVP, I wanted to get a version out as fast as possible and if I have to do the source admin UI selection, it’s going to take too much time, so I wanted to push that to the next version. Now, I can probably define the sources in xwiki.properties for now since that’s easy to code, and later add the Admin UI part.

#6

+1

+1

#7

LGTM

#8

I’m wondering about the privacy implications of this feature. The loading of the news would be another way that provides information about XWiki installations to xwiki.org and xwiki.com but depending on how images are loaded, this can also expose client IP addresses to xwiki.org and xwiki.com. As IP addresses are personal information, this could be a privacy problem. For example the privacy policy of xwiki.com from my understanding explicitly mentions that IP addresses are tracked to analyze user behavior. Unless we can make sure that in particular requests for content loaded on the client are exempted from this tracking, I think there must be an opt-in with an explicit approval of the privacy policy by each individual user before accessing this feature (i.e., before any requests are made from the client to xwiki.com/org). Alternatively, images could be requested through (and cached by) the XWiki installation. Any thoughts/plans on this?

#9

We have Legal Notice (XWiki.org) but that’s for the xwiki.org web site. ATM, each feature defines what it tracks. For example for Active Installs, it’s mentioned that the data sent is anonymous. It should probably also mention that the IP address is not saved.

Note that the Extension Manager has the same type of privacy issue that you’re mentioning here and I don’t think we mention anywhere that xwiki.org (nor store.xwiki.com) doesn’t track IP addresses for it.

Same for the video on the home page of XS, we don’t mention anything.

Maybe a Privacy page on xwiki.org listing all these privacy concerns could be interesting (It’d consist in a list of links to the extensions, each describing what it tracks or doesn’t track)?

This doesn’t look easy to implement and is also not nice for usability. Isn’t it simpler to say that we (xwiki.org) don’t track anything (since we don’t)? :slight_smile:

Also, as I said above this is not related to What’s New since it’s already happening for the EM, Active Installs or the video on the XS home page.

Not sure I understand. It’s the XWiki installations that will fetch the news from the various sources (xwiki.org blog and XWiki SAS paid apps store blog in the vote). And yes, the news will probably be cached for performance reasons, see What's New Feature (Proposal.WhatsNewFeature) - XWiki

Thanks for raising this concern.

PS: Don’t forget to vote on the 2 points. Thanks!

#10

BTW I don’t get any such privacy opt in question when using gitlab.

#11

The caching only talks about the feed which is what will be loaded on the server side. What I’m primarily concerned about are images that will certainly either be embedded in the content or as title image (the design page mentions “and an optional image”) as these will be requested from the user’s browser which reveals the client’s IP address together with a referrer that probably indicates the XWiki installation’s domain, thus allowing an association between IP address, browsing history of that IP address on xwiki.com and XWiki installation.

You mention the “XWiki SAS paid apps store blog”, where is that blog? I cannot see any blog on https://store.xwiki.com/ so I assumed it will be the blog on xwiki.com, but anyways, both link to the same privacy policy.

Of course it would be easier if just no data was collected, but the linked privacy policy on xwiki.com clearly states that data is collected and from my understanding we would display images served from xwiki.com.

EM and active installs only make requests on the server side, thus no client IP addresses should be submitted (unless there are images displayed by the extension manager). I also hope admins will remove this video on the XS home page before any actual users use the wiki but imho we should replace it by a more privacy-friendly solution like a video file bundled in the installation (as we already have in the help application).

#12

+1 for both.

Thanks,
Marius

#13

I’m wondering if it really makes sense to have several sources for the what’s new feature. By hard-coding these sources in the client in XWiki, it means we cannot ever change the server side. So what if we want to reverse our decision in a few years and decide we want to include forum news in the what’s new feature? Then all installations that haven’t been upgraded to the new version including this feature won’t get the news items from the forum - and I think that it could be important to reach in particular old installations. Why don’t we instead write an application that runs on XWiki.org and provides an API for the “What’s new” feature on some URL? This app could combine whatever sources we want/need, cache them and provide, e.g., a simple JSON API which would lead to a much simpler client (or provide an RSS feed for each user category that could be displayed using the RSS macro). The client wouldn’t need to care where these news come from, if they are from the XWiki.org blog, the blog of a sponsoring company or the forum - and we could change these sources any time and could be sure that they are displayed in all versions of XWiki.

#14

I assume the news sources will be configurable at least in xwiki.properties (in the same way the extension repositories are configurable).

I thought the plan was to have a single XWiki.org source (that we control and which we can change at any time to include forum news if we want) and to allow other sources, e.g. for a sponsoring company like XWiki SAS (which would be used to promote Pro Apps). So my expectation is that XS will have by default two news sources configured:

  • XWiki.org source
  • XWiki SAS source (as the top sponsoring company)

similar to how we have e.x.o. and store.xwiki.com repositories configured in xwiki.properties.

#15

But that doesn’t help if we want to change it as it means admins would need to manually apply the change to continue receiving news as we intend.

That’s not what the current implementation does, it explicitly exposes a component for the XWiki.org Blog. My understanding is that the forum would be a separate component. Both components would be part of the public API and thus cannot be removed without an API breakage.

#16

In my view the XWiki.org source is not something we would change easily, same as we don’t plan to change e.x.o. URL. And even if we have to change it then we would make sure the old URL is still working.

I haven’t checked the implementation, sorry. It doesn’t match my expectations. From my point of view XWiki.org should expose a single news URL that aggregates all the news we want to push from XWiki.org . Same for XWiki SAS: there should be a single news source that promotes Pro Apps and other products or services. Maybe @vmassol wanted to give administrators fine control over which news are displayed, but I think this can be done better by allowing administrators to filter the news by tags or category (e.g. if they want to be notified only about new releases).

#17

Results of the VOTE: 5 +1 (with opt out feature), no 0, no -1.

The VOTE is passed. Thanks

#18

@MichaelHamann @mflorea

So yes what Michael is mentioning is interesting and it’s actually UC107: Add the ability to contribute new News sources dynamically (without requiring a new version of the What's New extension) in the design page. I wasn’t planning to do it for the MVP.

Right now for xwiki.org we have decided on a single source, i.e. the xwiki.org blog.

But indeed, we need to think now about the future and the way I’ve currently implemented it wouldn’t be quite backward compatible if we were to add 2 sources for xwiki.org in the future. Right now I’ve implemented a xwikiorgblog source and not a xwikiorg source.

What I’m proposing to reconcile everything is the following:

  • Agree to use the RSS format for the xwiki.org source (the XWiki Blog RSS format to be precise)
  • For now and for the MVP, this means directly using the xwiki.org blog RSS (but using an extensions.xwiki.org/whatsnew type of URL to access it. Note: this is also needed to not request XWiki users to open another URL).
  • In the future, if we add different sources for xwiki.org, we’ll still be able to generate a RSS feed that combine all those sources and the only thing that will need to be changed is to where the extensions.xwiki.org/whatsnew URL points to.
    • At that point, this will mean developing a contrib app and install it on xwiki.org.
  • Do the same for the top sponsoring company source (aka XWiki SAS ATM) and agree to use a RSS format. This is also simpler for me for the implementation , as I just need to implement a single source type :slight_smile:
  • Regarding categories, require the RSS feeds to have something like the following categories (example from the xwiki.org blog): whatsnewcategories

PS: Re blog categories, it seems they’re not namespaces ATM so we might want to add a prefix to them like What's New for XS, What's New for XS:Admin User, etc. But that’s a detail ATM.

WDYT?

Thanks

#19

I didn’t mention it but the rationale for using RSS:

  • It’s standard and there are java libraries to parse it
  • It’s standard for news.
  • It allows XWiki users to see what’s new in XS but also if they want to follow the XWiki news, to read them using their browsers or favorite RSS readers.
  • All this without having us to invent a new format and tools around that format.
#20

Sounds good. RSS probably makes sense as the format has been designed for news. The only question for me is if for the client it wouldn’t be easier to have separate feeds per category instead of having to filter based on category. From what I can see, the blog application already supports creating feeds per category. The URL could be something like extensions.xwiki.org/whatsnew/<category>. That way, the client always gets some entries for every category and doesn’t need to deal with situations where, e.g., there are no entries for a certain category among the first 10 entries (I assume we somehow limit the number of entries in the RSS feed?) and then the client doesn’t know if there are any and it just needs to fetch the next 10 or if there are indeed none.