Recently I took over as the lead of the Ore Community Team and have been going over our guidelines to see where we could be less restrictive or make improvements. One of the biggest subjects has always been metrics for Ore and after discussing it internally we’ve come up with a proposal on changes we would like to implement but we would like community feedback before we finalize it.
I am aware that the subject of metrics has been a heavily debated one and am simply looking for feedback on our proposed changes. Please keep in mind that I welcome any and all feedback but that doesn’t mean it will be implemented.
Update: Thank you everyone for your feedback so far on both the forums and Discord. We’ve come up with a finalized version that we will put in place soon with API 8.
This is everything I’ve ever wanted.
As an aside, could it be possible to also send this message to the first person that joins the server with the sponge.command.config permission? It’s common, especially on Forge servers, to totally ignore the console unless something goes wrong.
Nope. Admins should look at the console… Making an assumption the user that joins first is an admin is bad - if they don’t have permissions to run the commands they can’t stop the spam.
It’s really important that the notifcations appear after the server has completely started to make sure they don’t get burried in the mess of console messages.
Though overall I really like the idea and am happy that my initial proposal has been advanced to this state and that Sponge itself will handle all the persky details about metrics.
I think the bStats author should be informed in a timely manner too.
And it may be worth backporting these changes into API 7. Or at least to make sure that a 1.12.2 version has these changes.
Perhaps instead of sponge.command.config, the message could be sent to users with sponge.commands.metrics (the permission mentioned in the document). These users will have permission to run the commands to enable/disable metrics and mute warnings, and so if they have access to that command it follows that they are (probably) one of the right people to inform about metrics collection.
Plugins still have the right to say anything to any user. I strongly suggest that plugins can message admins to encourage them to enable metrics, when the state is still undefined.
My plugins all advise the admins to enable metrics or to disable the message. The work required (opening, changing, saving the configs and reloading the configs ingame) is the same for both options (enabling metrics or disabling the message). I haven’t had any complaints yet.
Quite right, though that amendment is fairly important to the proposal - it’s our belief that if Sponge is going to hassle admins, it should do so exclusively.
I’d be interested in the text of your current notice, and the conditions of which it appears. We’re currently discussing what exactly the notice will say.
Almost all servers my plugins run on also have Nucleus. I made a small survey to determine which permissions are given to admins: nucleus.mute.base. Based on that, only once a note is sent if metrics are disabled and the message hasn’t been disabled (the config).
To be quite honest, that sort of message is exactly the motivation for that amendment to the guidelines - I originally used the phrase “holding servers to ransom to enable metrics collection”, it was rather extreme but I think it conveys the point.
I really like the confirmation by bStats that my plugins are used. And which are used the most, to have some priorities which plugins to work on more.
Until now I could be almost sure 100% that those numbers are correct. It definitely is the motivation to develop and support plugins for free.
I agree. And I think that’s why so many devs are passionate about metrics.
But it’s really not ok to spam users/admins with these messages unless they activate metrics.
And since Sponge will take care of the messages the plugins really have no business in asking again. Not only will it throw out the concept of unified messages, but also kinda defeats the purpose of the system.
We appreciate that, and we’re incredibly grateful that you’re developing for Sponge - but we don’t want plugins circumventing Sponge (having their own notices) and especially bending admin’s hands to enable metrics (having a notice when they are disabled).
I don’t think I’d do that, but It’s my plugin and it’s a short message that impedes nobody using it. If they’d rather uninstall the plugin than disable the message, shouldn’t that be up to them? Ore isn’t quality control. I disagree with the locking down of metrics but I at least understand that it’s there because of the security concern. To ban message nagging - that’s just nannying IMO. If they don’t like how you’ve wrote your plugin, they don’t have to use it. Banning a message being printed to the console is just silly.
At the same point what’s the point of Sponge displaying a message if the plugins are just going to come in and nag folks anyways?
While I’m trying to be less restrictive in how we handle Metrics itself (by exposing the state of things to the administrator when the server finishes starting) it would be nice to have everything fall under one global message.
I’m open to feedback on the matter but overall not many have expressed concerns on limiting plugin nagging.
