Add nextchange field

[pludi]

Adds an optional nextchange field, indicating when the open/closed state might change in the near future. Could be used to indicate when it will close so people don't start the commute only to encounter closed doors.

[gidsi]

It sounds like a nice idea, but i don't know how you would achieve that and how reliable this information would be in the end. Is it for something like "I'm going now and will open the space in 30 minutes"? Or something like "There is an event at the space so it will be open then"? Or is it more like a machine learning thing like "Usually the space is open today in approx 2 hours"?

I'm just not sure how reliable this information would be and how to communicate this. Providing this information sounds quite complex and quite error-prone.

[pludi]

It's intended towards humans, as in "The space is open now, but the last person will leave with a high probability at the specified time" or even "It's not open now, but the next time it will open will be around $TIME". How, or even if, it is populated is up to the Space.

[dbrgn]

@pludi how do you plan to populate the field if it's implemented?

What we do at Coredump is to use the state field like this:

This conveys the information when the space will be expected to open again. It's also displayed in the MyHackerspace app.

[pludi]

For us it's mostly the first example cited. We have some members that only visit sporadically, as well as guests, and we're a bit remote with regards to public transport. So it would be interesting for those to know if they decide to visit that it probably will or will not be open when they arrive.

[dbrgn]

Yes, but how do you expect people to update the field in practice? Will they open a webpage and enter their expected time of departure? Do you think that will work? Also, when / how is that field cleared?

Just trying to understand how you think the field will be used and populated in practice. In my experience a chat or a hackerspace phone where you can call to ask how long someone will remain there works better.

(We even have trouble getting everyone to use the mechanical binary people present counter... Something like the system above would not work for us.)

[pludi]

Internal webpage where people can enter their planned time of departure. Our script updating the static JSON will then populate the field, or remove it if the time has passed.

Of course I don't expect that every member will fill this out when present, which is why I added it as an optional field. It's almost like the message field you're adding at Coredump, only instead of an text representation it's a timestamp. Might even be used in tandem, with one representing the estimated time, and the message being used to provide details to it.

[the-metalgamer]

I think that this field would be nice, but I do also see practical limitations.

[gidsi]

Internal webpage where people can enter their planned time of departure. Our script updating the static JSON will then populate the field, or remove it if the time has passed.

Of course I don't expect that every member will fill this out when present, which is why I added it as an optional field. It's almost like the message field you're adding at Coredump, only instead of an text representation it's a timestamp. Might even be used in tandem, with one representing the estimated time, and the message being used to provide details to it.

How about an experiment? Can you implement it in your space as an ext_ field and find out if people will use it? I'm pretty sure that there are a lot of people with that problem, i just don't know if that's the right way to solve it (most spaces i know have a phone that gets called if someone is in that situation) but maybe this works out a lot better.

Would you be up for that try? :)

[dbrgn]

Using the ext_ prefix is a good idea. (In general, we should use ext_ fields a lot more, as "proposed standards", and only include them in the official spec if a significant amount of spaces use them.)

[pludi]

Sure, we'll try that.

[gidsi]

Great, would be great if you could provide a new pull request if everything works out :)