Do not deduct points for short descriptions from federated plugin implementations

[stuartmorgan]

See #992 for background.

The useful description for an implementation package is to say what the package it implements is, and its platform(s). As a result, all of our 1P implementation packages are losing points on "The package description is too short." because they have descriptions like "macOS implementation of the url_launcher plugin."

Anything we added to that description would be noise, so I propose, as with #992, that this be skipped for packages with the implements keyword.

[sigurdm]

Usually you would want the federated plugin implementations to be unlisted anyways.

Otherwise copying the description from the mother-plugin and adding "for linux" would be an easy fix.

[stuartmorgan]

Usually you would want the federated plugin implementations to be unlisted anyways.

They are, but people can still get to the pub pages for them. And in some cases actually need to, such as to see platform-specific notes.

Otherwise copying the description from the mother-plugin and adding "for linux" would be an easy fix.

Sure, but that makes the description worse. A normal description sounds like a package intended for direct use, and doesn't explain what it is actually for. Adding some lorem ipsum text to the end of the description we currently use until it's long enough would also be an easy fix.

The issue here isn't "I can't figure out how to artificially hit the minimum", it's "the current system is incentivising making descriptions of federated implementations worse".

[sigurdm]

@jonasfj should we reconsider?

@stuartmorgan is there currently any way that pub could determine if a package is a federated plugin implementation?

[stuartmorgan]

Yes, it's trivial. From my original post above:

I propose, as with #992, that this be skipped for packages with the implements keyword.

(Also, I believe pub already detects implementation packages and handles them specially; IIRC that's by graph analysis of default_package references though, and implements would be slightly better in this case.)

[jonasfj]

I have mixed feelings about special casing for generic guidelines. The description length requirement originates from SEO guidelines.

IMO, if a package is unlisted, is points then really so important?

If they are important is it really so bad to honor SEO guidelines?

I don't really mind, it's just another weird corner case.

I suppose my preferred way of doing this is making the description length check a lint, and then have a comment to opt out of it. Like we do with naming lints in generated FFI bindings..

[stuartmorgan]

The description length requirement originates from SEO guidelines.

Regardless of the origin, the effect is the packages are getting points deducted for no useful reason.

I understand that there's an argument about points being "deducted" vs "granted", but it's pretty clear from feedback in other issues that at least a subset of people view points that packages aren't getting as some form of penalty against the package. (And since the idea of points is clearly to create an incentive system, I don't think that's a surprising reaction.)

IMO, if a package is unlisted, is points then really so important?

On one hand, no. On the other, as discussed above, people can still go to these packages. If they do, this is what they will see:

If it's not important that these points are missing, why is there a big red X? Why is the 10/20 in red? The UI is very clearly communicating "this is not good" with those signals. Clearly the designers of this UI think it's important, and want readers to believe it's important.

And in particular I think having that signal paired with having "flutter.dev" as the publisher isn't a great look.

[jonasfj]

Regardless of the origin, the effect is the packages are getting points deducted for no useful reason.

It is useful, is not? from: https://pub.dev/packages/google_maps_flutter_platform_interface

It's used in multiple meta-tags, these are used when generating "embeds for links":

    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="robots" content="noindex" />
    <meta name="twitter:card" content="summary" />
    <meta name="twitter:site" content="@dart_lang" />
    <meta name="twitter:description" content="A common platform interface for the google_maps_flutter plugin." />
    <meta name="twitter:image" content="https://pub.dev/static/img/pub-dev-icon-cover-image.png?hash=vg86r2r3mbs62hiv4ldop0ife5um2g5g" />

    <meta property="og:type" content="website" />
    <meta property="og:site_name" content="Dart packages" />
    <meta property="og:title" content="google_maps_flutter_platform_interface | Flutter Package" />
    <meta property="og:description" content="A common platform interface for the google_maps_flutter plugin." />
    <meta property="og:image" content="https://pub.dev/static/img/pub-dev-icon-cover-image.png?hash=vg86r2r3mbs62hiv4ldop0ife5um2g5g" />

    <meta name="description" content="A common platform interface for the google_maps_flutter plugin." />

I personally dislike these.. but twitter, google chat, discord, and friends generates embeds like this... some use the description, some don't, some use hover... SEO guidelines is what we have formalized.

I don't really see why these constraints should not apply to all packages.

I understand that there's an argument about points being "deducted" vs "granted", ....

hehe 🤣 -- yes, I agree we definitely didn't sell this :D

---

In the case of:

macOS implementation of the url_launcher plugin.

Why not just write:

macOS implementation of the platform interface for url_launcher plugin.

Or:

macOS implementation of the url_launcher plugin, see url_launcher.

Or:

macOS implementation of the url_launcher plugin, prefer using url_launcher directly.

Or:

macOS implementation of the url_launcher plugin, prefer using url_launcher instead.

Or:

Implementation of macOS support for the url_launcher plugin.

All of these are >=60 <=180 characters.

---

If we really want to we could also make pana count whitespace characters in the description, and have pub.dev trim them, so that there is a mechanism for opting out -- feels like a bit of hack though 🙈

[stuartmorgan]

Why not just write:

macOS implementation of the platform interface for url_launcher plugin.

That is a worse description; the exact mechanics of federated implementations are not relevant to clients.

Or:

macOS implementation of the url_launcher plugin, see url_launcher.

This is also worse; instructions to the client don't belong in the description.

Or:

macOS implementation of the url_launcher plugin, prefer using url_launcher directly.

Same.

Or:

macOS implementation of the url_launcher plugin, prefer using url_launcher instead.

Same.

Or:

Implementation of macOS support for the url_launcher plugin.

This is forced and awkward, making it harder to read for the sole purpose of making it longer.

All of these are >=60 <=180 characters.

And all of them are worse. As I said above:

The issue here isn't "I can't figure out how to artificially hit the minimum", it's "the current system is incentivising making descriptions of federated implementations worse".

What positive outcome is served by encouraging these packages to have longer, but worse, descriptions?

[sigurdm]

Discussing this we will lower the limit to min 40 chars.

[sigurdm]

We never took action on this. We should still do this.

Do we update the client as well?