Related ticket https://pagure.io/Fedora-Council/tickets/issue/502

Thank you for spending time on this.

I agree with the need for the Event Policy. I would avoid the Goal/No-Goal sections as you put them in the policy.

I think we need to consider two different parts of this work: 1) the Event policy 2) the current task to setup the initial policy and allow it to be built and extended further with experience.

For that work item part indeed we can scope it down and start with the very strict and objective criteria based on the local laws, before we dive deeper into the less formalized areas.

But the event policy as a document which we will setup and develop, can not have visa requirements as a non-goal. It is a goal of the policy, it is not a goal of our first steps in establishing the foundation for that policy.

I would avoid the Goal/No-Goal sections as you put them in the policy.

I was not sure how should I communicate the goal of the document. I repeatedly pointed to people that I was trying to focus on 1 specific problem, either on the forum or during my workshop, but people still proposed to expand the scope each time. So being explicit was a way to avoid the problem.

However, I agree, now that the document is at the last step before being merged (eg, people who comment know what this is about), that's no longer a issue and should be removed.

I think we need to consider two different parts of this work: 1) the Event policy 2) the current task to setup the initial policy and allow it to be built and extended further with experience.

That was part of my initial proposal, with one policy for location, and another policy that explain how we extend the 1st one. I have been told to simplify it, hence the merged document.

But the event policy as a document which we will setup and develop, can not have visa requirements as a non-goal. It is a goal of the policy, it is not a goal of our first steps in establishing the foundation for that policy.

That's why this is not "Event Policy", but "Event DEI Location Policy" with a rather narrow focus. And I am quite convinced that a policy like this one (kinda a checkbox policy) is not the right way to deal with visas, or venue accessibility.

I spent lots of time trying to figure the whole visa stuff, but this depend too much on 1) the budget 2) the participants 3) the travels. If people give me unlimited budget, I can easily solve the problem. I can just afford a private jet for each attendee and organize Flock on the private island I rented with the unlimited budget. But without that, that's a rather complex optimisation problem with plenty of trade-off that need to be discussed between humans.

For example, do we need to take in account visa requirements during travel ? If we choose Jamaica for Flock 2025 because that's visa free for people from India, we also need to account for budget so sponsored people fly to Kingston without going to the US (as they would otherwise need a visa, which negate the main reason to go to Kingston). From a quick look, a flight from BLR to KIN next month cost 1000€ on the 11th of November if you stop in Miami. If you want to avoid the US, then it cost 1600€, flying to YUL and MUC (and also take longer).

And that's just assuming we optimize on visa for 1 nationality, but things get harder if you add more variables, more country and the fact that we have no idea if getting a visa is hard or not. And in order to optimize for that, we need to know who is coming, but who is coming depend on budget and budget depend on where you go, which is what you want to find (which I feel can be solved by some gradient descent, but the policy can't be "use the power of computer science").

So if we have a policy, that would be extremely vague and hand wavy, because there is no other way afaik. That's why we struggle and why I couldn't find any example.

As for the question of a venue policy, it came from people wanting it to be accessible. That's a worthy goal, but too vague and hard to predict as accommodations may be very specific, so it depend again on budget and audience. For example, let's look at sign language for deaf people. That would fall on the purview of accessibility, but the ASL (American Sign language) is different from the LSF (french sign language) who is different from the 298 others sign languages. If we decided this Flock to get sign language support, we would have likely faced logistic issues. What if we had a french deaf contributor, how hard would it have been to find someone in Rochester that speak LSF ?

Another example, are the norms around accessibility the same around the world ? if I say "yes the hotel in Rochester is wheelchair accessible", can I assume that it is good enough for someone from another country, one that likely use different unit ?

For those 2 reasons, I think that we need multiple policies, not just one, and likely policies that would be wildly different than the checkbox/criteria at bid time approach I propose here.

For example, I do not think we should have a policy that say "the venue need to be accessible", because that's meaningless without saying to whom. What we would need is a policy that say that we aim to make it accessible and a process to make it so. To go back on the sign language example I gave, maybe the process would be "get a quote for a interpreter as part of the bid process and set aside money for that". If no one request it, then we keep the money (cause, that's quite pricy, I think we were speaking of 5k € in France for a 2 days event).

Maybe the process for accommodation for a wheelchair user could start by asking to people in advance, and as a policy, select the party venue to be fun even in a wheel chair, etc.

I kinda see the whole process of building flock as a pipeline, and those policy are either here to gate a location (visa, laws) or to build the event itself (adding accommodations). And you likely know better than me that this wouldn't be wise to have a single pipeline step that does everything as smaller separate ones are easier to reason with.

Now, of course, we can also have a "event policy" document that mainly serve as a index for all those non yet written documents. But I feel a index is overkill for now.

Also, while the policy is titled "Event location DEI policy", at its core, it is more a risk management policy. As pointed out at the start of the ticket (and everywhere else), there is more and more protests/controversy/discussions around the topic (and I can even give a example from last week ), but based on what I have seen, actual incidents are quite low. So the policy is mostly here to avoid ruining our efforts around DEI, and having events organizers having to deal with a controversy as they are already overloaded.

And so I bring the risk management angle because when discussing with Justin in the meeting yesterday, the question of bad actors came back to my mind (around discussion of whether hackfests should be covered or not). By bad actors, I mostly have in mind something like far-right influencers that would increase the risks by whipping a controversy.

For example, if we organize a hackfest and it is not covered by the policy (let's say translation hackfest) as discussed with Justin and it happen to be in what I would call a DEI hostile location (for example, Russia), I can think of a few risks that would caused by bad externals actors.

One could start a controversy, either by pointing we can't apply the CoC (and so that we are hypocrites, and Coc is just fluff, etc), or in a more extreme case, ask followers to call the cops (like this ) and cause problems to local organizers.

s/council/Council

I don't like having an "and/or" here. Make the responsibility unambiguous. The Council can always overrule the DEI team's decision, so it should either be assessed by the DEI team and then referred to Council or it should go directly to Council.

s/council/Council

I fixed and used the --force to push the fix.

I don't like having an "and/or" here. Make the responsibility unambiguous. The Council can always overrule the DEI team's decision, so it should either be assessed by the DEI team and then referred to Council or it should go directly to Council.

Fair point. I think that I am not sure which one is best and maybe that's why I left it for later.

On one hand, the Council has the authority and legitimacy to decide, but maybe not the time.

On the other hand, the DEI team will likely have the expertise and the time, but unlike the Council, do not have a very formal structure, and less insurance to be staffed with people.

I like the document. I think it strikes the right balance.

After the first reading, I was worried about the "hard criteria" and basing the decision on the formal law. The formal laws sometimes trail behind the actual practice. US is famous for it's quirky town and parish laws that were passed at some point and formally are still on the books, even if almost nobody remembers about them. In Great Britain homosexuality was partially illegal until ECHR struck down their law in 2000. But despite the law being formally valid, I'd argue that in 1990's the actual climate and practice was good enough that Flock 1998 in London would have been OK. Similarly, countries in central Europe unfortunately have many discriminatory laws… in particular Poland. But the actual practice may or may not be a problem and a closer evaluation would need to be required. But the document allows the Council to override some of the requirements, with a justification. I think this is good enough. Effectively it means that we would start with a strict evaluation based on the letter of the law, and possibly ignore some of the problems after careful evaluation.

To be fair, I suspect that actual "organic" problems will be quite rare anyway, I can't think of one that happened since 20 years. However, my biggest fear is not that kind of problems, but risk of "manufactured" problems, either from a external actor (likely malicious), or from a reputation point of view.

To follow your example, let's assume that we find the time travel device that bcotton used to properly estimate release date, and use it to go back to London in 1998 to organise Flock. While it look like a normal phone cabin, it is bigger inside, so we can fit the community without too much trouble (other than the usual logistics one).

Male homosexuality was decriminalized since 1967 in part of UK, and all of UK around 1980 after Dudgeon v. U.K.. The part that was removed after the ECHR case of A.D.T. v. U.K. in 2003 was the part that criminalized intercourse between more than 2 men. And while I know the 80s weren't exactly tolerant for queer people ( I know someone who spoke about violent incidents she faced when she was younger and in UK ), I agree that in practice it would have been less a issue in London in the late 90s for foreign travellers.

Now if we look closer to the A.D.T. affair, we can see that someone must have called the cops on him, because cops do not usually show with a warrant randomly at your house and find videotapes. The same happened in Lawrence v. Texas, the case started due to jealousy between 3 guys, one of them calling the cops on the 2 others.

And I know we have a few polyamorous people in the Fedora community, I know we have a few queer people in the community and I know there is people who belong to both groups, and some that belong only to one. I even know at least 1 male RHer in a trouple with 2 others guy (but he is not working on Fedora).

Would those people be at risk with the UK law in 1998 ? That's hard to tell, but once you factor the risk of denunciation, it might become less rare. For example, Debian (and Fedora to some extent) has to deal with a relentless harasser who suggested to call the cops on one of his target in the past, and who continue to harass people as of today. I would argue that this kind of person could harass some people in the community by calling the cops on them if they knew in advance they go to Flock London 98 (assuming a timetravelling phone).

And so the question is not if in practice, the law would be applied more that the risk if it is applied.

Another issue for U.K. in 1998 is the famed section 28 legislation, as it was still present, and this could have caused problem if Flock location was a school/university, which is not uncommon. For example, Flock 2014 was in a university in Praha. FOSDEM and Devconf.cz are in universities every years. In the past, several FUDCOn were in school or government buildings, such as FUDCON Milan 2011, FUDCOn Santiago 2010, FUDCon Boston 2005 to name a few.

So if Flock 98 London is organized in King's College London, we would face uncertainty on whether we could hold a DEI team meeting and/or a Fedora pride meetup. It would be less of a issue in a private hotel.

And even if the administration of the college say "this is ok", we could still face the risk of someone starting a campaign pointing to us not respecting the law (assuming that someone can send Youtube video/podcast/social media messages to the past before those were invented, of course).

But that's also why we have the hard and soft requirements. A law that criminalize general promotion of homosexuality as discussed in Turkey this week would be a hard "no", as it would prevent holding a DEI team meeting for example. A law like the one in UK (the gross indecency one) could be a softer "no" with a lengthy comment as I think indeed it would be harder to show a risk, but it might not be 0, and so would let the council decide with enough information depending on other proposals.

Thank you for the long explanation — I learned a lot I didn't know. But I think that your conclusion and my conclusion are effectively very similar, to make an informed decision in the nonobvious cases.

So, to answer @bcotton point, I would propose the following change, replace

Each covered event should be assessed by the Fedora DEI team and/or the Council in a timely fashion (ideally in a month time frame)."

by

Each covered event should be assessed by the Fedora DEI team in a timely fashion (ideally in a month time frame). The Council will then have to decide based on Fedora DEI team input, or take over the duty of assessing if the Fedora DEI team is not able to do the assessment."

This way, we can have:
- a clear path forward if the DEI team fold
- a clear process for the case if doesn't fold, in line with our governance
- a great source of joy for @bcotton by removing ambiguity

Hm, maybe "(ideally, within a month)". That seems less grammatically tortuous.

Seems like a good idea, document should be as clear as possible. In fact, maybe remove "ideally", cause we need a time limit, not a ideal case.

I changed the MR as we discussed

+1

+1

+1

Commit cad9b6b4 fixes this pull-request