New "battery_ok" event type reason to mirror "low_battery"

[dbaty]

Context: I am working on an implementation of MDS for BlueLA, a station-based electric car sharing service in Los Angeles. The suggestion below would apply there and also for any service where devices can autonomously recharge their battery on docks (charge points).

When a customer returns a device to a dock, the battery of the device may be too low for the device to be available for another customer. The service then yields an unavailable event type with the low_battery reason. That part is fine. Then the device charges itself at the dock (without needing any human interaction). When it's done, the device becomes available again. I think that the maintenance_drop_off event type reason is not appropriate here, because there is no (human) maintenance per se. I hence suggest a new battery_ok event type reason for the available event type.

If this sounds reasonable, I'll happily write a pull request.

This is related to #77, albeit different.

[marie-x]

Makes sense to me. I would probably rename low_battery to battery_low and then add battery_charged as its pair.

[thekaveman]

Seems to me that this handles the situation in #77, especially given the naming suggested by @Karcass.

[dbaty]

I created #237, using battery_charged as proposed by @Karcass.

As for renaming low_battery to battery_low as suggested, I am less inclined to do that. I am not sure how we should handle such changes: my guess is that we should support both types (low_battery and battery_low) and mark the old one as deprecated in version N+1 ; and eventually remove the old type in version N+2 (versoin N being the current version). That should be properly documented. [*]

[*] More generally (and this is going off-topic), I think that a proper, manually edited changelog would help everyone migrate from one version to another. I reckon that it's a bit of additional work, especially in these early days of the specs when things move a lot. But it would be much more convenient and reliable than reviewing each commit, which are not always easy to follow. The update of this changelog could very well be a requirement for each pull request, shifting the burden on the authors themselves instead of the editors/maintainers.

[thekaveman]

@dbaty

More generally (and this is going off-topic), I think that a proper, manually edited changelog would help everyone migrate from one version to another.

I think this is what we're trying to capture in the Release Notes and ReleaseNotes.md but agreed the process could be better for everyone. See ReleaseGuidelines.md and please suggest any improvements you can think of.

[dbaty]

This issue should be re-opened since #237 has been reverted by #254.