Move modules related to web services to a separate package on the module listing page

I don't think RDF is a web service. It's closer to an SEO tool the way we use it. Web services colloquially mean non-HTML things, and RDF gets put into HTML.

So the only modules not in the "core" group that are in core are some multilingual modules. I think if we are going to do this then we need to have a think about ALL the modules in core.

Alex: Please provide better guidance on what "think about" means, or else based on historical evidence this issue will sit here untouched for the next year. (I've seen that happen a dozen times.)

As is, there's a clear UX benefit to this change on its own, and the precedent of separating things out in core has already been set.

How about doing what Commerce does in D7, which advises contrib modules to use the "Commerce (contrib)" package? We could have "Multilingual (Core)", "Web services (Core)", "Fields (Core)", etc. Or, even better, we could/should do #1868444: Introduce tags[] in module.info.yml file to categorize modules by provided functionality. instead.

But I think this should be discussed in an issue with more than 5 followers (6 after I post this :P).

And a small patch review: since the package string now contains a space, it should be wrapped in quotes.

I'd suggest naming it the other way around: Core blah, Core foo, Commerce whatever - that way all core stuff is kept together alphabetically.

I'd be fine with #9.

I think this needs to be done for the whole of core, see #2064727: Separate Core modules into separate packages on module page

@Crell: I was thinking about having it as 'Core Web Services', Core Multilingual and so on, and i guess it depends where other non core web service modules go. Would contrib modules exist in the same web services package as the core ones, or in a separate package?

If contrib modules go into the same package then you just want to call it 'Web Services' (and hopefully flag some as being core in some way)

If contrib modules go in a different package then you end up with:
...
Core Web Services at the top of the list
...
...
...
Web Services at the bottom of the list
...

In which case I guess it's better to have:
...
Web Services
Web Services Core
...

I thought it was a quick simple decision, but it seems like it's not

So you're going back to my #8, nice :)

@amateescu: Not necessarily. I think it just highlights that in different situations you may want it a different way. Which makes tagging a useful proposition.

-- moved comment to a general discussion thread #2064727: Separate Core modules into separate packages on module page

changes seem to be already present in core.