Calendar from what I can see doesn't have a joinable policy, so not sure what that editable by invitees policy would really prevent.

Do you have a specific problem you are trying to solve? https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#describe-problems

Yeah, there's no separation of Join/View policies currently.

The thinking is that if you can see the event (and thus see the time and location) there's nothing physically stopping you from attending, and that the cues users use to choose whether or not to attend events are primarily social/cultural cues (nature of the event, event description, etc), not technical cues, so that there's likely very little value in adding complexity to align the button state to the host's expectations. If host/attendee expectations are misaligned (e.g., Joe plans to attend the event "Chad and Evan 1:1"), it's also possibly better that someone mark themselves as attending ahead of time so you can sort it out privately before they show up in person.

This might not actually be right, at least in some cases or with some users or situations, and we might separate the permissions at some point. If most users were unthinking robots with no cultural or social awareness we'd obviously make the permissions explicit, expecting them to both ignore all social cues and attend events purely based on their technical permission to join them, and also love configuring things. I think the balance of concerns may not tip this way for human users, but even for actual humans, having a state cue may ultimately be worth the additional complexity. Still, I'd like to wait for these use cases to clearly arise first.

Broadly, Calendar is still a prototype and the permissions model is one of the rougher areas. I think we're likely to separate policies around access to availability (vs access to events) a bit so that default view policies can be more private. That is, today it's hard to let everyone see that you'll be busy from 2PM - 3PM while only showing a more limited set of people that you'll be taking a nap. But this is a reasonable use case, and a common capability in other shared calendaring applications and we'll likely end up with something that looks similar.

Hey, sorry for the dump and run report.

An example would help: https://phabricator.wikimedia.org/E46

Basically, I made an event for people to join so that others in Phab know not to expect us on those days. Anyone is able to join the event, which is fine. I don't think there's an expectation that the Calendar app is so fine grained yet to deal with the example @epriestley gave above.

There is a nice difference between joining an event and subscribing to one, which I appreciate.

The confusion (and this task) came from seeing this:

Semantically (iow: not for security reasons) it makes more sense for the people who can edit the event be the ones attending. To put it another way, when I saw those options I was confused and surprised by them and it made me doubt myself/what I was doing.

I don't have really strong feelings about this, but I thought it was worth it wrt UI/UX to at least think about it.

Ah, thanks. That makes sense.

I think "Event Host" and "Event Attendees" are likely reasonable object policies to add under much the same reasoning as "Project Members" is justifiable in T9019 (briefly: friendliness, useful to set as defaults), although I'd like to sort out the permissions model with slightly more clarity first. It's possible that figuring out a good model for availability will create some complexity in pursuing this. If it doesn't, these changes are pretty straightforward.