Change in policy on support tickets

1

Hi all - May First made a pretty big policy change with regard to our ticket system - the official announcement is here:

https://mayfirst.org/en/post/2019/content-content-our-support-site-will-be-private/

I’m re-copying below - we are interested in member feedback so please share your opinions!

We are making changes to our support ticket policy that have political implications and so we want you, as members, to know about these changes and share with us any thoughts you may want to share.

Nearly all communications between members seeking help and support with our online resources happens via one web site: https://support.mayfirst.org/. Launched a full 12 years ago, our support site contains a remarkably rich archive documenting not only our organization’s history, but also a critical history of free software, and the experiences of movement activists in using it.

It has served us well for over a decade, however, times have changed.

We originally launched the support site intentionally making all tickets fully public. If you asked a question, everyone in the world could read your question and our answers to the question. This approach was based on a commitment to collaboration among members, to transparency on how we answer tickets, and a commitment to serve the greater good by providing a wealth of technical questions and answers to the world.

However, over the last 12 years, web sites and all data on web sites have become fodder for marketers, surveillance capitalism and right wing attacks. The questions posted to our support site unintentionally provided a map of not only our organization’s infrastructure, but the relationships and inner workings of our member organizations.

At the same time, our political efforts at using our open ticket system to foster collaboration and a commitment to mutual support among our members have fallen short. While we do witness a small number of members using answers to other tickets to help underestand their own technical difficulties and sometimes offering their own experience and answers, our more common experience is member surprise and sometimes outright horror to discover that their tickets are publicly available and showing up in web search results.

In response, the Leadership Committee has taken the difficult decision of making all past tickets “sensitive” and setting all future tickets to “sensitive” by default. When a ticket is marked “sensitive” it can only be read by the person who reported the issue, the people cc:ed on the issue and the support team.

As of Wednesday, May 15, all tickets on our suport site have been marked sensitive and are no longer publicly viewable.

While we have taken action to protect the privacy and safety of our members this should not be framed as a political win. We have been forced to reposition ourselves to safer ground to face the forces of surveillance capitalism, state repression and a growing fascist movement that is taking the revolutionary potential for an open and unmediated communications medium like the internet and perverting it into a reactionary force.

The struggle continues. May First is still firmly committed to an open and transparent web, to publishing our technical experiences and knowledge freely and openly, and to building mutual aid and support among our members. Now is the time to regroup and decide together the best strategy to continue this part of our work.

Toward that end, we are inviting all members to participate in an open (and still public) discussion of this problem via our discussion forum here: [post link to discourse].

We need the best thinking of all members to move forward with our vision during this dark period of internet repression- so please join the discussion!

1 Like
2

Hi Jamie,

Is there the option of protecting the tickets from public access, while allowing authenticated users access to the full range of tickets?

3 Likes
3

That’s an interesting idea. It might require having three rather than two privacy options (fully public, shared with members, private).

3 Likes
4

I agree with luigibai-htx
We learn of other tickets. Sometimes we can write a suggestion about another ticket.
If the system is all “sensitive” then it will be better to do support by email.
The ticket system will not be useful more.

2 Likes
5

Yes, maybe tickets can also be read by registered users but not visible by everybody online.
I have found some useful answers looking at other people tickets.

2 Likes
6

I too would like to support the idea of allowing registered/authenticated users/members to be able to view other people’s tickets. I think it’s a beneficial resource to have as an ancillary knowledge base.

1 Like
7

Overall I think the decision is sensible. I have read through others tickets looking for answers - sometimes finding them, sometimes getting some clarity on another direction to go. It has been valuable, and often in ways there is probably no record of or way to measure.

At the same time, while searching through others tickets, I have found helpful info but guessed by the way it was written, “I’d bet this person doesn’t know this support ticket is publisheg out in the open.”

At the same time, I tried to write my tickets in a form that would be useful to others, but sometimes hesitated because I wanted to describe something that I didn’t necessarily want public.

I think the suggestion of “authenticated access” in the comments above is ideal, but if not possible making everything private is better than everything public. And I say that with a twinge of sadness.

2 Likes
8

I appreciate the decision. I think it’s also worth investigating that tiered transparency structure people are suggesting, although of course some members may still want to keep at least some of the details of their tickets private even from other authenticated MFPL members.

2 Likes
9

I want to focus on this:

We want to foster collaboration and mutual support. In that sense, I agree with other comments that creating three levels of privacy would allow us to continue collaborating internally. I remember conversations about commons (bienes comunes) with friends who said “a commons is not a chaos or a system that anyone can enter at any time, rather a commons has community norms, and only the people who participate in the commons have access to it.” So, if we think of MF/PL as a commons, then it’s a house with a lock on the door, and all the members have the key. The servers, for example, are a commons and access to them is restricted to members.

And for the past 12 years we tried letting the support system function as a more open commons, but now we have hostile neighbors, and we think it wise to build a fence, to bring the support system into the same protection as the servers.

We can look for ways to summarize what we learn from the support system and share it with the free/libre software movement. We can continue sharing other things from MF/PL with the general public, such as the podcasts, the news, the official documents. We can continue sharing what we choose to share at movement events. So while I realize that putting a privacy fence around the support tickets means that people outside MF/PL won’t have access to this info, I understand it as a strategic decision. And hey, if the support tickets are really valuable to them, maybe they’ll join MF/PL! (but I doubt that many people or organizations will do so, it might at least prompt them to reflect on the process. Maybe we can put a statement about commons, fascists, and surveillance capitalism on the front page of the support site, so that people who can’t get in can instead read an explanation of why we put a fence around the tickets, and encourage them to read the official documents and consider joining MF/PL.)

Another technical point: are any of the tickets cached in the archive.org wayback machine? Or Google page cache? Or some other public cache?

Regarding the public-ness of this conversation: I wonder about the decision to leave this site public. What’s the value? What’s the contribution to society wellbeing? What if we only allowed authenticated members, and if we want to show the conversation to a trusted friend, then each forum page can have a password that allows read-only access to only that page? Or just copy the page text and paste it in an email to that trusted friend. And if the general public wants to know what we’re talking about, can we release a summary podcast or blog post that doesn’t contain sensitive information? Could we at least have a section of the forum designated as “authenticaed users only”? There are things it might be useful to share with other members, but I’d rather not share with the general public.

Also, I keep in mind that for any really sensitive info, I wouldn’t share it with all members, since I assume that sooner or later someone malicious could infiltrate the organization or the servers. Computers and the internet are copy machines, after all, so anything I write could get copied at some point.

On to the next point: “a commitment to mutual support among our members”. This seems really important to me. Here in [country that isn’t the US or Mexico] we call a collective work effort a “minga” or in Kichwa “randi randi” refers to reciprocity. How can we foster more participation and mutual support among members? Seems like a theme for the Leadership Committee to consider, and to have more conversation about, since it extends (or could extend) beyond the support-mayfirst-org site. During a period a few years ago, I participated more actively on the support site, both posting questions and answering what I could. But I just ran out of capacity, plus I got severe tendonitis and had to stop using the computer for a couple years. From a tech support perspective, perhaps we can encourage each organizational and individual member to use the support site more actively. Perhaps we can encourage organizations that have technical capacity to contribute a few hours each month to answering questions and writing how-to guides on the support site and the wiki. Perhaps some organizations with tech support capacity could form a stable relationship contributing tech support capacity to a particular software, or a particular person on the support team, in order for their energy to flow in an organized way and thus have more impact.

Maybe creating an area in the forum for member-only conversation and fostering communication among organizations could result in more mutual support. I imagine that if we feel more connection with other members then we’ll be more likely to support each other. I might be a special case (first living in [city that isn’t New York] and now in [country that isn’t US or Mexico]) (<< that’s the sort of info I would be more specific about on a member-only forum), since I’ve never met anyone else from MF/PL in person, so these forums have been my only connection with y’all.

cheers!

1 Like
10

I would suggest reverting this policy and simply make the ticket system member only access, while maintaining the option for a user to mark a ticket sensitive

All the years I have worked with bug reporting, one of the main features is that similar problems might be researched, learned from and not duplicated by opening a new ticket for the same issue over and over.

And for those that are ‘shocked’ their ticket info is “public”, closing it to member only addresses that to a degree. For something that is actually “sensitive”, people need to become informed and to be responsible. Perhaps a final step can be added to the ticket process that forces the user to select from 2 or 3 options, with a clear and concise explanation given for each, i.e.:

This trouble ticket is
( ) Sensitive (access will be restricted/limited to ‘authorized support staff’ ???)
( ) Normal (visible to all other logged-in mayfirst members)
( ) General (visible by anyone, anytime, totally public)

I don’t really see any use for the latter…but others might?

And on another level, summarily making all prior tickets “sensitive” is a major change. I would think it should have been discussed by the membership before being implemented. This has deprived us of any meaningful self-help.

Will this new policy then require more paid staff and eventually higher dues to compensate them for work that now only authorized staff will be able to assist with?

11

I see very little benefit from having a public option.

I think a 2-tier system is sufficient, with Normal being the default, not “Sensitive”

( ) Sensitive (viewable by authorized staff access only)
( ) Normal (the default) viewable by all logged-in members

Self-help is crucial. And should limit duplication of ticket issues and lessen the workload on paid staff, and curb the need for dues increases.

The idea of self-sufficiency can’t be overstated. It builds a stronger community when people become more able to take care of their own needs and be less dependent on others. The latter seems to foster hierarchy. Mutual assistance is far more horizontal.

12

Pattrickgibbs: Regarding the analogies of locked doors and fences. I think our main goal isn’t to keep the public out, it is to keep members safe. Unfortunately authenticated access is our most viable immediately available solution for this, simply because filtering out all metadata from ticket posts is a very difficult problem.

It is true that any private or publicy available web caches like wayback machine will still have copies of any support tickets they’ve cached up until now. That is not something we can revert and is characteristic of the way being “public” on the internet changes our concepts of being open and public when machines and algorithms consume everything that is online and remove the option of removing information from the public sphere or “unpublishing”.

I love what you’ve shared about the concept of collective work. In México “tequio” is a popular term for this. Now that we’ve voted to be a coop both in name and practice this is an important discussion. Along with collective ownership comes collective responsibility. I think it is part of the challenge of building a stronger sense of community within the organization. It is a difficult balance since we don’t all participate with equal conditions. Coming up with strategies that recognize our different roles, different technical capacities and time constraints is important but I like where you are going with this.

Regarding this forum itself. I agree that the decision to make these internal deliberations public should also be up for of debate. Without the necessity for more tech this Discourse instance can already be a space for conversation between members.

13

Historicuss: I think trying to build awareness among members about the risks of making metadata public has been our strategy up until now but in my opinion it puts an unfair burden on members to anticipate errors under unforgiving conditions. Once something is public reverting it may not be an option. Of course we should all be more aware of the risks involved in publishing on the internet but does that mean we shouldn’t try to reduce harm if we can?

I agree it is unfortunate that this change has impacted yours and other members ability to search other member tickets to attend to your own support needs without interacting with staff. I am curious how often this issue has come up for you during the past few weeks. The idea of making all non-sensitive tickets available to members by default seems to be gaining traction and hopefully we’ll be able to open up the access for those members who really take advantage of it.

As far as the impact on support staff workload, in practice I have not seen an increase in number of support tickets over the past few weeks. We can’t know how often members were able to help themselves through access to these tickets but the number of members using the ticket system to help each other probably registered <10 per year. I think that is still significant for political/ideological reasons but so far the recent change doesn’t seem to have increased our workload in practice.

14

In a previous ticket dkg has suggested we do 3 things which I generally agree with. I will paraphrase them here:

  • Make information about the change and reasoning behind it clearly available to members and the public
  • Develop and publish guidelines that would help members and staff determine under what conditions a support ticket should be complete private between the issuing member and support staff, accessible to members or completely public.
  • Double down on providing useful support information via the support wiki or other channels

In the context of what has been discussed here so far about fostering collaboration and mutual support, I think those last two are processes that could really benefit from more member participation.