Add "Tentative" or "Not preferred" option

[AvaS314]

Proposed feature or solution

When planning, sometimes you are unsure of whether a time will work or you could make it work although you'd prefer not to. Having an additional option would help when filling out crab.fits, as you currently have to make a decision about whether a possibly busy time should be marked as free or busy.

I'd imagine that there could be some sort of toggle between marking as available and marking as tentative so that the basic path of filling out a crab.fit remains unchanged. I'd also imagine that a tentative availability would be considered exclusively as a secondary sort in the ordering of how many participants are available, and not as a fractional equivalent. That is, a time slot with 5 available participants and no tentative participants would be considered "more available" than a slot with 4 available participants and any number of tentative responses, but "less available" than a slot with 5 available participants and any number of tentative responses.

Alternatives

I briefly considered suggesting an arbitrary priority system of availability but that felt too complex for many reasons. I think a single intermediate tier provides enough increased flexibility without adding too much complexity.

Additional information

The iCal spec defines a BUSY-TENTATIVE type. However, the Google Calendar API does not support this value as I believe there is not a mechanism to mark your events as tentative. Other calendar apps such as Apple Calendar and Outlook do support that value so this could be helpful for those integrations in the future.

I'd be willing to take a shot at implementing this myself but I'd like to get some feedback on the implementation first.

[altsalt]

Related to #131

[drinkablebreeze]

This system is essentially a vote for the best meeting time. The current method is approval voting, where people mark all the times that they're available for or that they "approve" of. This is good, but it's not as expressive as it could be. While it seems simple enough to bucket possible times into a binary "available" or "unavailable," people often prefer certain times over others with more granularity.

A more expressive and representative voting system could use multiple preference levels to show different degrees of support and preference order. A system that can do this is STAR Voting, and is well-designed for this kind of use-case. People would score each time slot from 0 to 5 stars (or "🦀"s!). The top two highest scoring meeting times advance to the runoff round, where the winner is whichever meeting time was preferred over the other by more people. Why the runoff? Even if neither of the top two times were good for you, you still get the chance to make sure the winning meeting time is not one that's completely unworkable for you.

This expressiveness shouldn't come at the cost of the simplicity of the current system. If someone just wants to mark when they're available like in approval voting, they can just mark all their available times 5 stars and everything else 0. The heatmap could still be used by the organizer to pick the best time, and the winner of the runoff could just be a suggestion to consider. (e.g. "The highest scoring options are time A with an average of 4.23 and time B with an average of 3.90. Between these two options, time A was preferred over time B by 55% of people.")

Other implementation thoughts:

• Someone's "availability" for a time needs to change from being represented as a bool to a u8, with valid values in the range 0-5 instead of 0-1.
• Since the meeting time may be longer than the time slot chunking, we'd consider the score for a possible meeting time to be the average score given to the time slots that make up the meeting time.
• Similarly, in the runoff round someone's vote would be determined by the average scores they gave to each of the two finalists. The meeting time with the higher score would get that person's full vote.
• The heatmap visualization could be simplified to show an average score on the 0-5 scale instead of totals.

I know @GRA0007 closed #131 saying something like this would add too much complexity. So I'm interested in piloting a fork to explore how it would turn out. If it's useful and not too complex, maybe it can be upstreamed into crab.fit.

[drinkablebreeze]

It is done! Check out the source here and the changes here. This adds support for multiple degrees of preference expression (0 to 5 stars) and uses STAR Voting to automatically calculate the best event time given your desired event duration. Tabulation details are here.

A public instance is available at starbestfit.com, which is renamed to Star Fit to emphasize the new features. The how-to shows a quick demo of it in action!

@GRA0007, if you're interested in upstreaming these changes into Crab Fit, the star branch has all the new scoring and tabulation logic without the renaming and other deployment-specific things that are on main. Let me know if you want me to open a PR!

These updates should be backwards compatible with existing crab.fit databases. If the score for an availability is not found in the database, then it is assumed to be 5 stars. Unavailable times are 0 stars.

[CaptainBoggle]

Yay! Thanks