Improve information about the level of support of extensions

Development
#1

Hi devs,

Right now on e.x.o and in the EM, we have the concept of “Recommended” and the concept of “Developed by”. However there’s no concept of who are the individuals, groups or companies offering support for these extensions.

It would benefit our users to know what options of support they have for various extensions.

I’m thus proposing the following:

  • We introduce the concept of “Supported by” in both the Repository Application and in the Extension Manager. The idea is that:
    • “Recommended” becomes a criteria of current quality (note that the name “Recommended” is not the best since I’m not sure it’s a good thing to recommend an extension that is not supported for example)
    • “Supported by” is a criteria of commitment, i.e that the extension will get better and that there’s a way to ask questions and get answers
    • Note: We could also imagine dropping “Recommended” and only having “Supported by” and then say that the current recommended would become: “having at least one ‘supported by’ entry”. However:
      • It’s harder to implement and we will still need to support “Recommended” for backward compat reasons (existing XWiki instances will ask to return recommended info from e.x.o)
      • We wouldn’t be able to express that an extension is of a current good quality, if there’s nobody supporting it (edge case probably)
      • We wouldn’t be able to indicate that an extension is supported by someone while not currently bering of a good quality (edge case probably)
    • WDYT? Should we drop “Recommended” and have only “Supported by”?
  • We allow sponsoring companies to edit this field on e.x.o to add the following information:
    • Name of the company (string), e.g. XWiki SAS
    • Support plan name (string), e.g. Silver level
    • Support plan URL (url), e.g. https://xwiki.com/...
    • Support plan level (integer), e.g. 1
    • Notes
      • The best exact format is to be discussed, this is just a first thought.
      • The level is needed to be able to query extensions to answer the question, e.g. “list all extensions supported by XWiki SAS, in their silver plan or above”
      • We may want to avoid duplication and enter the company name, and plan name + level in a single place, and then in extension metadata, only use ids.
  • Have a column in exo to allow filtering by “supported by” and “at least a given support level”(at least be able to query for all extensions above a given level of support)
  • EM should display that information when displaying extensions and should also allow filtering by “supported by” (and above a certain level of support)
  • We allow a sponsoring company to add one or more such entries for each extension (in case they provide several support plans for an extension).
  • (if we keep recommended) We update the definition of recommended to remove the supported part from it and keep only the quality level.

WDYT?

Thanks

1 Like
#2

+1 in general to introduce the concept of supported extensions, but indeed we’ll need to refine a bit the details

I guess it make sense, yes. It’s hard to recommend an extension when nobody is behind to fix bugs.

That sounds way too restrictive. That would make impossible for another company than those defined by https://www.xwiki.org/xwiki/bin/view/Main/Supporters/SponsoringCompanies/, or simply an individual, to indicate they support some contrib extension they implemented.

If you want to get rid of the “recommended” status, then “supported” cannot only cover professional paying support.

Not a fan of having two different fields for the support plan value and display name since those are supposed to be in sync I guess. It would probably make more sense to have a single field with an id and use translations of a db list to get the display name.

#3

Will “Supported by” cover each and every extension of XWiki?

#4

It would be filled for supported extensions yes, ie whenever someone or an org supports it.

#5

Indeed let’s be more precise. We could say:

  • Any extension committers are allowed to edit this field for their extensions
  • Sponsoring companies are also allowed to edit this field for any extension they support

WDYT?

That wasn’t the point. When I said We allow sponsoring companies to edit this field on e.x.o to add the following information: I didn’t mean that ONLY sponsoring companies are allowed to edit this field.

Sounds good.

#6

I’m not sure: you cannot have “Recommended” without “Support by” but will every “Supported by” extension be “Recommended”? i.e. I could create an extension and commit to support it but for some reason decide to not respect the xwiki.org dev best practices: do we want to recommend it?
It’s very theoretical since I’m not sure we really check every recommended extension manually anyway. But I guess we’ll want to keep the EM to display recommended first, so better be clear about what recommended means and feels like dropping it to “Support by” only change its meaning.
Think also about all the extensions that are supposed to be maintained by people who are not contributing to XWiki anymore: I can easily imagine that we don’t update systematically the “Supported by” field when it’s people and they stop contributing.

+1

Actually, shouldn’t it be just a name and a URL linking to a description page of the exact plan details? Feels like it would allow any evolution in the future with a simple format.

However this put some hard constraint on the format if a name is not enough…

well as I said above for me “Recommended” should still include “Supported by” if we keep it.

#7

I mean, for instance, those extensions which have Pro version.

#8

There is no such extension on extensions.xwiki.org, and XWiki SAS will be marked as supported by for all extensions in store.xwiki.com I guess.

1 Like
#9

What about them? If someone supports them (the “free” version), then the “supported by” field will be filled.

1 Like
#10

Yes, except that this doesn’t allow filtering all extensions supported by a plan… As I said I my first post, the need is to be able to answer “list all extensions supported by XWiki SAS, in their silver plan or above”.

You can solve this in 2 ways:

  • By having a plan number. In this case, we can have a single entry “XWiki SAS, silver plan”, and filtering for >= 1 (assuming silver = 1)
  • By adding an explicit entry for each an every support plan. So you’d have “XWiki SAS, silver plan”, “XWiki SAS, gold plan”, “XWiki SAS, platinium plan” for every extension supported starting with a “silver plan”, and filtering for the exact plan id or name.

It feels to me nicer to have less stuff displayed.

WDYT?

#11

I think it is a good idea to replace “Recommended” by a clearer definition. I think we should have some predefined categories for “supported by” if this is supposed to be used more generally. A single developer or a group of developers offering free “community” support on a best-effort basis is something very different from offering a paying support contract. I think this should be indicated very clearly with, e.g., a different color and a different prefix like “Paying support by” or “Free community support by”.

At least for extensions.xwiki.org I think it would be a good idea to let these support entries automatically expire, for example by automatically removing the entry if the last release was more than a year ago, or by requiring that a year is specified and allowing at most two years to be specified (such that the entry needs to be updated roughly once per year) - just to avoid that actually non-supported extensions have this label.

I fear having just one entry might be confusing for users. If they have a gold plan and see that an extension is supported in the silver plan, they might think that it is not supported in their plan unless the entry says “XWiki SAS, silver plan and above” in which case it might still not be clear what “above” is.

#12

That all depends how you see “Recommended”. If you view it as a quality criteria only then you don’t need “Supported by” to be included in its definition.

That doesn’t really matter for Recommended. What matters is the quality of the runtime extension.

Yes, “Supported by” would be the same as introducing “Recommended by”, except that the word “Recommended” is a bad one, and “Supported” is much better.

Yes, the “supported by” field will eventually be modified if an individual or org is MIA.

I’m also in favor of keeping a single concept since that makes it simpler for our users (more complex to implement for sure but simpler to use).

#13

I like the idea.

#14

I had exactly the same doubt and I asked XWiki SAS about this (more precisely: Ludovic, Clément, Oana) and they all said that it was 100% obvious to all users that they would understand that platinium > gold > silver.

I’m also ok to have all plans listed explicitly if we can find some display that is not too intrusive in both exo and EM. It certainly makes the implementation simpler and allows to have only 1 simple column for filtering.

#15

If we could have some extra metadata (that is defined once, not several times), we could also implement something where we store all plans explicitly but have a configuration to say that, e.g., platinum support should be hidden if gold support is specified - basically, having a list of support levels that should be hidden when the given level is present. That way, we would have the data for easy filtering, wouldn’t need complex comparison logic and could still have a (potentially) nicer display.

#16

I noticed yesterday that we currently do not mark macros that are bundled in XWiki as “recommended”, meaning that if you search for a recommended macro on the extension repository for a certain purpose, you won’t find the bundled ones. As an example, imagine you’re wondering how to create a tag cloud in XWiki and search for it. You come to the tag cloud macro. However, it’s not recommended so you start wondering if there is another, recommended way (that would also, e.g., be covered by your support contract). The information that the extension is actually bundled is quite hidden in my opinion and not immediately obvious.

I therefore propose that we take this opportunity to make this information more consistent by also indicating the support level for bundled extensions. This could also be an opportunity for sponsoring companies to be more selective which bundled extensions they actually want to support. I think we should have a mechanism to automatically add certain support labels (like community support) to all extensions that are part of XS in order to not further increase the required work for maintaining the extension repository and also offer a way for sponsoring companies that they support all bundled extensions.

2 Likes
#17

We do not mark any extension bundled in XS (XS = set of extensions), not just macros. Your point about macros is true for any extension too.

Yes, right now, as a user, you need to understand that “bundled in XS” means supported by the author (ie “XWiki Development Team”). BTW https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/ also lists all features (ie extensions) found in XS.

The reason we did this was to make it simple for us, ie not to have to add recommended for bundled extensions since that’s obvious. But I agree that our Repository app code on e.x.o could automatically add the Recommended checkbox when “Bundled in XS” is set, on page save.

I don’t think the use case has been expressed yet. For example XWiki SAS will support any bundled extensions in XS. What you said, makes sense if you create different distributions other than XS which will not have the same extensions bundled. It’s fine with me to do this. However, as you mentioned, it’s going to be a lot of work for companies like XWiki SAS to mark all XS-bundled extensions as supported, so we’d need to add code for them in xwiki.org to do the same as for “Recommended” above for the XWiki Development Team (by setting the supported by fields upon save when “Bundled in XS” is set).

So in summary: +1 for your idea.

#18

To sum up, the main decision to take is whether to keep “Recommended” and add “Supported by” or not.

So far:

  • Thomas: +1 to have only “Supported By”
  • Simon: +1 to keep both
  • Vincent: hesitating but prefers to keep only “Supported By”

Let’s try to agree.

Point 1

After more thinking I think we should drop “Recommended” and keep only “Supported By”. I think the main reasons are:

  • It’s hard to have the “Recommended” status in sync with the reality and we’ve been failing so far to add/remove that status on extensions.
  • It’s much easier to delegate the quality level to Individuals, Groups or Companies. They become responsible of associating their name with a certain level of quality of extensions they support. This means a lot less maintenance for the XWiki developers. Users will recognize and trust “supported by” names.

Point 2

I’d also like that we agree about Michael’s proposal of automatically dropping all “Supported By” fields if an extension has not had a release in a year, in order to have up to date “supported by” fields. Now since it’s possible that an extension is still of good quality if it didn’t have a release in on year, we could send an email when the “supported by” status is removed, to give the opportunity to past supporters to reiterate their support (when registering a support “organism” on exo, we would ask for an email address).

Point 3

As proposed by Michael, all extensions will have their “supported by” field filled, even extensions bundled in XS. We would create a “XWiki Development Team” support “organism” on exo. We would also add the “supported by” entry automatically for “XWiki Development Team” upon page save when “Bundled in XS” is set.

Point 4

For each “Supported by”, we allow to specify 1 or several support plans and we allow to filter the global extensions LT by “Supported by” and by “Plans”. Any sponsoring company or author/contributor of an extension is allowed to register himself/herself as a supporter. Sponsoring companies can register themselves on any extension.

Please express your opinions on these 4 points.

Thanks

#19

+1 for 1, though I would prefer to have a “free community support” vs. “commercial support” differentiation. Basically, we would have two kinds of supported by that result in differently styled labels to make it clear if you can/should pay for support or if you can get free support from the developer/a group of developers on a best-effort basis.

+1 for 2, though I think it would be nice if, instead of performing a release, you could also just update a date field on the support status. I think the criteria should be date field or last release is less than a year old to avoid adding extra maintenance cost. Further, I think it would make sense to allow that “commercial support” entries don’t expire, just community support ones. Basically, the main purpose would be to avoid that people state that they provide community support and then lose interest. For “commercial support” I see this less as a problem as long as the company is around. If we should get a problem with companies claiming support and disappearing, I guess we can re-discuss this but then maybe we should discuss requiring a refresh of the whole company entry and not individual extensions.

+1 for 3 and 4.

#20

+1

+1 for automatic dropping but -1 to rely only on the release date (by the way we don’t really have this information in extensions.xwiki.org or EM API in general right now), many extensions work just fine with a last release older than 1y (it’s really not that long for a stable extension).

The date field idea sounds good.

+1 for 3 and 4

1 Like