As winter turns to spring and the snow starts melting this is necessary to find routes that probably still have snow on them.

The data from opendata.swiss has the route geometry, and various pre-existing fields for the route length, maximum ascent, and so on, but there is no direct field that contains the route's minimum elevation, so it cannot be used directly in a filter.

Assuming that this is the sort of thing that must be both possible and straightforward, I asked the QGIS community on the Fediverse. @tlohde@fediscience.org was kind enough to reply, and this post is adapted from their suggestions.

The rest of this post assumes you have already followed the steps in Finding snowshoe routes using Swiss OpenData and QGIS.

Outline

We are going to:

1. Create a new column in the snowshoe data to contain the minimum elevation of each route.
2. Apply a QGIS function, z_min, to populate this column.
3. Update the existing filter to exclude routes with a minimum elevation below 1,500 metres.

Creating and populating the column

1. Open the “Field calculator” for the snowshoe attribute table.
   1. Open the layer menu by right clicking the “schneeschuhwanderwege_2056.gpk” layer in the layer pane (bottom left)
   2. From the menu click “Open Attribute Table” to open the attribute table pane below the map.
   3. Open the “Field Calculator by clicking the “Edit” button and then the “Open field calculator” button in the toolbar above the attribute table
2. Create a new “min_elev” column in the data.
   1. Ensure “Create a new field” is checked.
   2. Enter “min_elev” in the “Output field name” field
   3. Enter “z_min($geometry)” in the “Expression” field
   4. Click “OK”

This has created a new column in the snow show data called “min_elev”, with a value calculated as the lowest Z point (elevation) in the route geometry for that row.

You can verify this in the attribute table. Scroll the table to the right and you will see the new min_elev column at the end.

Exclude routes below 1,500 metres

1. Click the “Edit” button in the attribute pane to disable editing.
2. Open the layer menu by right clicking the “schneeschuhwanderwege_2056.gpk” layer in the layer pane.
3. Choose “Filter...” to open the Query Builder.
4. Click the “Test” button.
   1. If you are using the query from yesterday you will see a dialog message, “The where clause returned 39 row(s)”. If you are using a different query the number of rows will be different.
   2. Click OK to dismiss the dialog.
5. Edit the query to add a final clause, AND min_elev >= 1500.
6. Click the “Test” button again.
   1. If you where using the query from yesterday you will see a dialog message, “The where clause returned 9 row(s)”. So 30 routes that dip below 1,500 metres have been removed. If you were using a different query you will see a different number of results.
   2. Click OK to dismiss the dialog.
7. Click OK to dismiss the Query Builder

Sites like SchweizMobil have a list of routes and useful information; length, total ascent/descent, route maps, and so on. But support for searching for routes that meet specific critieria is lacking.

In my case I wanted to find routes of between 5 and 12km, up to 300m of ascent, and taking no more than 4 hours. I'd like to see this on a map (so I can get a rough idea of where in the country they are), and quickly click between them as part of making a decision.

SchweizMobil doesn't support this sort of search, and you're left to scroll through routes, open them in different tabs, and eyeball some of the data to decide whether the route is suitable.

There's a better way. opendata.swiss provides all the necessary data under a range of licenses.

This data can be loaded in to QGIS, an open source desktop geographic information system (GIS) for displaying and manipulating map and related data.

Together this allows you to create your own personalised map of suitable routes.

At the end of this process you will be able to see a route on the map, including the elevation profile, like this:

Install and run QGIS

Install QGIS by following the instructions at the download page at the QGIS Web Site.

Launch QGIS after installation.

Install QGIS plugins

QGIS supports plugins that provide additional functionality, and we will use two:

• QuickMapServices
• Swiss Geo Downloader

Both of these plugins make it easy to load data from external sources directly into QGIS.

QuickMapServices displays data from OpenStreetMap directly in QGIS. We will use this to provide the map of Switzerland and routing.

Swiss Geo Downloader allows you to search for and import Swiss OpenData in QGIS.

There are other ways of accomplishing both of these tasks, the plugins make it straightforward.

To install these plugins:

1. From the QGIS menu choose “Plugins > Manage and Install Plugins...”.
2. Search for “QuickMapServices”, select it, and click “Install Plugin”.
3. Search for “Swiss Geo Downloader”, select it, and click “Install Plugin”.
4. The plugins dialog should look like this. The exact list of installed plugins may differ depending on the version of QGIS you have installed, but “QuickMapServices” and “Swiss Geo Downloader” should both be listed and checked.
5. Close the “Plugins” dialog.

Use OpenStreetMap as the base layer

1. From the QGIS menu choose “Web > QuickMapServices > OSM > OSM Standard”.
2. A world map should appear in QGIS, and the “OSM Standard” layer should appear in the “Layers” pane at the bottom left.
3. Zoom in on Switzerland. It should look like this:

Import snowshoe routes

1. From the QGIS menu choose “Plugins > Swiss Geo Downloader > Swiss Geo Downloader”.
2. You may be prompted to switch to the Swiss coordinate reference system, LV95. Choose “Yes”.
   1. If you are not already zoomed in to Switzerland the map will become very distorted. This is normal. The distortion will disappear when you zoom in on Switzerland
3. A “Swiss Geo Downloader” window pane will open, with a search bar at the top.
4. Enter “snowshoe” in the search bar.
5. Choose the “Snowshoe trails” dataset from the results. Section 3 of the window should show “schneeschuhwanderwege_2056.gpkg”
6. Click “Download”, and choose a directory when prompted.
7. The “schneeschuhwanderwege_2056.gpkg” layer should appear in the “Layers” pane

Improve visibility of the routes

The snowshoe routes may be difficult to view on the map. To improve their visibility:

1. Double-click the “schneeschuhwanderwege_2056.gpkg” layer, to open the “Layer Properties” dialog.
2. Adjust the colour, width, and other properties. For example, click “effect neon” and set the width to “1mm” to quickly make the routes stand out.
3. The available routes should now be much more visible on the map:

Filtering the routes

The map is currently showing all ~ 200 routes. To filter them to your own criteria:

1. Right click the “schneeschuhwanderwege_2056.gpkg” layer and choose “Filter...” from the menu to open the “Query Builder” dialog.
2. Use this to build a query for the routes you care about.

The query builder field names are in German, and have the following meanings:

• NameR: String, route name
• NrR: Number, route number (e.g., 101 is SchweizMobil route 101)
• BeschriebR: String, route display name
• LaengeR: Number, length in kilometres, e.g., 8.1
• HoeheAufR: Number, ascent in metres
• HoeheAbR: Number, descent in metres
• ZeitStZiR: Number, estimated time in minutes, e.g., 225 = 3h45m?
• TechnikR_en: String, difficulty level (english), e.g., “blue”

For example, the following query filters to routes that are:

1. Between 5km and 12km
2. Have a maximum ascent of 300m
3. Take 4 hours (4 * 60 = 240 minutes) or less

LaengeR >= 5 AND LaengeR <= 12 
AND HoeheAufR <= 300
AND ZeitStZiR <= 240

After applying the filter the map will look like this (your map will look different if you used different filter criteria).

View an elevation profile

QGIS can display elevation profiles for routes.

To activate this feature:

1. Choose “View > Elevation Profile” from the menu.
2. The “Elevation Profile” pane will open at the bottom of the display.
3. Click the small “Capture Curve from Feature” button in the “Elevation Profile” pane.
4. On the map, find the route you want to see the elevation profile for.
5. Click the route.
6. The elevation profile for the route will appear.

Click a route to open a web page

The “schneeschuhwanderwege_2056.gpkg” data also contains URLs for each route. QGIS can be configured to open that URL if you click the route.

1. Right click the “schneeschuhwanderwege_2056.gpkg” layer and choose “Properties...” from the menu to open the “Layer Properties” dialog.
2. Choose “Actions” from the list of properties on the left of the dialog.
3. Click the green “+” button to open the “Add New Action” dialog.
4. Use the following action settings:
   1. Type: “Open URL”
   2. Description: “Open SchweizMobil”
   3. Action Scopes: Check “Canvas”, leave other options unchecked
   4. Action Text: [% ChmURL_en %]
      1. This will open the English page. Other options are [% ChmURL_de], [% ChmURL_fr], [% ChmURL_it], or [% ChmURL_rm] for German, French, Italian, and Romansh respectively.
5. Click “Ok” twice to dismiss both dialogs.

You can now enable the action in the QGIS toolbar.

Challenges when doing this include:

• Deciding how to structure the document.
• Deciding when the document is complete.
• Over-stuffing the document with information that is not relevant to the reader at that time.
• Ensuring the reader has the necessary prerequisite knowledge to understand the material.

To combat those problems start the document with a “Synopsis” section that consists of:

• 1-n paragraphs that provide a very brief introduction to the topic. That might be an overview of the topic, or perhaps a description of the specific problem the documentation will help you solve.
• A list of 0-n bullet points that start “Before reading this document you should:“.
  • Each bullet point should list a task to complete, with a link to material that explains how the reader can complete the task. The task might be an activity they need to complete, or a document they should read before this one.
• A list of 1-n bullet points that start “After reading this document you will know:”

I have found this to be invaluable when organising your thoughts.

1. If you cannot write a brief introduction to the topic that is an indication you either do not understand it well enough to write about it, or the topic is too complex to cover in a single document and should be separated into smaller documents.
2. The “... you will know” bullet points serve several functions:
   1. They're your “to-do list” of things to write about in the document. You know the document is complete / ready for editing when you have ticked off each bullet point.
   2. If you find yourself writing more than ~ seven bullet points that's a good sign the document is going to be too complex, and should be broken in to smaller documents.
3. Similarly, the “... you should:” bullet points have several functions:
   1. They allow you to be explicit about what is not covered in the document.
   2. They clearly direct the reader to the other material.
   3. They highlight material that may be missing. If you find yourself writing an entry in this section but do not have documentation that tells the user how to complete this task you have discovered another document you need to write.

This works whether you are writing a stand-alone document or one that is part of a collection.

I first adopted this technique when I was co-editing the 2nd edition of the FreeBSD Handbook, and although that is long in the past, today's handbook continues the tradition.

The synopsis for the “Wayland” chapter is a good example. It starts:

An installation of FreeBSD using bsdinstall does not automatically install a graphical user interface. This chapter describes how to select, install, and configure a Wayland compositor, which provides a graphical environment.

Before reading this chapter, you should know:

• How to install additional third-party software.
• How to identify and configure drivers for your graphics hardware.

After reading this chapter, you will know:

• How to configure FreeBSD to host a Wayland graphical environment.
• How to install and configure a Wayland compositor.
• How to run programs designed for the older X Window System.
• How to configure remote desktop access to a Wayland graphical environment.

In that example:

• The introductory paragraph provides context for the reader.
• The “... you should know:” bullets clearly explain prerequisite knowledge, and direct the reader to the right place to learn that knowledge.
• The “... you will know:” bullets tightly scope the content of the document, and allow the reader to rapidly determine whether this document is going to be helpful for whatever task they are carrying out.

Inspired by a discussion in the joinmastodon.org Discord.

Someone's writing an app processing incoming HTTP requests with a Content-Type header. Specifically, they want to handle the case where the content type is application/json.

They noticed some clients are sending an unnecessary charset=utf-8 parameter in the content type, and wondered how they should properly handle this parameter.

They're doing this as a learning exercise so wanted to avoid leaning on an existing library if possible.

The discussion went back and forth a little bit between validation and parsing without really getting in to the meat of it, it's too long for a chat message post, and I'm not aware of a good discussion of the topic elsewhere, hence this post.

What to do?

The difference between validation and parsing

I use the terms to mean the following.

You validate incoming data to decide if your code should continue on the happy path, or branch to an error handler because the data is invalid. The incoming data will not be used again.

You parse incoming data to validate it, and to extract the information to a different type for use elsewhere in the program.

To use Pachli as an example, the code validates the content type of incoming data as application/json because if it's not then an error has occurred. The content type is not used after that.

Pachli parses a server's version string to a dedicated Version type to hold a semantic version because the version information is used elsewhere in the code to make decisions.

Parsing to the dedicated type once means the rest of the code knows the version is valid and can be reasoned about, instead of repeatedly having to re-parse the version string.

The Content-Type header

The Content-Type header specification is defined in RFC 9110 sect. 8.3. Using ABNF the grammar for the header is

token          = 1*tchar

tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / DIGIT / ALPHA
                 ; any VCHAR, except delimiters

parameters      = *( OWS ";" OWS [ parameter ] )
parameter       = parameter-name "=" parameter-value
parameter-name  = token
parameter-value = ( token / quoted-string )
  
media-type = type "/" subtype parameters
type       = token
subtype    = tokenContent-Type = media-type

Content-Type = media-type

It also notes

The type and subtype tokens are case-insensitive.

and gives these examples

text/html;charset=utf-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
text/html;charset=UTF-8

RFC 8259 defines the application/json media type, and is explicit that this type does not have a charset parameter, writing:

Note: No “charset” parameter is defined for this registration. Adding one really has no effect on compliant recipients.

What to do?

The original questioner can now decide whether they want to validate the header as application/json, or parse the header to a more specific set of types.

Validation

From the definition of the Content-Type header and the application/json media type we can see a sensible strategy for validation would be:

1. Remove everything from the header value after-and-including the first occurrence of ;
2. Trim any whitespace from the start and end of the string
3. Perform a case-insensitive comparison of the value with application/json

Step 1 handles malformed clients or servers that emit variations of application/json;charset=utf-8 (or any other charset). While technically not correct this is unlikely to impede interoperability.

Step 2 is also for malformed clients or servers. The specification does not allow spaces before the primary type (application), and there may be spaces between the subtype and the ; that was removed in step 1. Again, removing these should be harmless and improves interoperability.

Step 3 validates the header contains the correct value.

Parsing

Parsing the header is appropriate if the application is going to branch based on the type and subtype. For example, different handlers for application/json and application/activity+json.

To do that I would create specific Python types to represent the parameters and types that can appear in a Content-Type header, and have a function that parses the header and returns one of those types.

The types should include an explicit Unknown value to indicate an unhandled type, and can either raise errors or return an additional error type.

For example:

import re
from dataclasses import dataclass

# This is an example to demonstrate parsing a value to one of a
# specific set of types, distinct from simply validating the value
# matches expectations.


@dataclass
class BaseParameter:
    """
    Base class for all parameters.

    value: Value of the parameter as it appeared in the header.
    """
    value: str


@dataclass
class Charset(BaseParameter):
    """A 'charset=...' parameter."""
    pass


@dataclass
class UnknownParameter(BaseParameter):
    """
    An unknown parameter.
    
    name: Parsed name of the parameter
    value: Parsed value of the parameter
    original: Original parameter string as it appeared in the header.
    """
    name: str
    original: str


Parameter = Charset | UnknownParameter
"""Parameters that can occur in a content-type header."""


@dataclass
class ApplicationJson:
    """The application/json content type."""
    pass


@dataclass
class ApplicationActivityPlusJson:
    """
    The application/activity+json content type

    charset: Parsed value of the 'charset' parameter, if present.
    """
    charset: Charset | None


@dataclass
class UnknownContentType:
    """
    An unknown content type.

    type: Parsed name of the type
    parameters: Parsed list of parameters, if present.
    original: Original content type as it appeared in the header.
    """
    type: str
    parameters: list[Parameter]
    original: str


ContentType = ApplicationJson | ApplicationActivityPlusJson | UnknownContentType
"""Possible content type values."""


# THIS IS NOT A PRODUCTION QUALITY PARSER
def parse_content_type(val: str) -> ContentType:
    r = re.compile('^(?P<type>[^;]+)(?:;(?P<parameters>.*))?')
    m = r.search(val)
    if m is None:
        raise ValueError
    type = m.group('type')
    if type is not None:
        type = type.lower().strip()
    match type:
        case 'application/json':
            return ApplicationJson()
        case 'application/activity+json':
            parameters = parse_parameters(m.group('parameters'))
            charset = ([e for e in parameters if isinstance(e, Charset)][:1]
                       or [None])[0]
            return ApplicationActivityPlusJson(charset)
        case _:
            parameters = parse_parameters(m.group('parameters'))
            return UnknownContentType(type, parameters, val)


# THIS IS NOT A PRODUCTION QUALITY PARSER
def parse_parameters(val: str) -> list[Parameter]:
    if val is None:
        return []

    parameter_strs = val.split(';')
    r = []
    for parameter_str in parameter_strs:
        parameter_str = parameter_str.strip()
        (name, value) = re.split(r'\s*=\s*', parameter_str, maxsplit=1)
        match name.lower():
            case 'charset':
                r.append(Charset(value.lower()))
            case _:
                r.append(UnknownParameter(name, value, parameter_str))
    return r


if __name__ == "__main__":
    print(parse_content_type('application/json'))
    print(parse_content_type('application/JSON'))
    print(parse_content_type('  application/json  '))
    print(parse_content_type('application/json ; charset=utf-8'))
    print(parse_content_type('application/activity+json'))
    print(parse_content_type('application/activity+json;charset=us-ascii'))
    print(parse_content_type('made/up; charset=utf-8; some=parameter'))

    match parse_content_type('application/activity+json;charset=us-ascii'):
        case ApplicationJson():
            print('It was some form of application/json')
        case ApplicationActivityPlusJson(charset):
            print('It was some form of application/activity+json')
            if charset is not None:
                print(f'Charset was {charset.value}')
        case UnknownContentType(type, parameters, original):
            print(f'Content type "{original}" was not recognised')

Anything else?

Additional checks could be performed.

• Instead of ignoring the charset parameter, parse the value and confirm it is utf-8. If it is not then signal the error in some fashion so the operator of the offending client/server can be informed. For example, receiving application/json;charset=us-ascii should be a red flag somewhere.

#Pachli (website, google play, f-droid, github, mastodon)

To quote from https://pachli.app/pachli/2023/09/06/hello-pachli.html:

Pachli is an application (now) and an association (aspirational).

Pachli-the-application is a best-in-class open source Android application for Mastodon and Mastodon-like servers. If you’re familiar with Tusky then you’ll love Pachli.

Pachli-the-association is intended to provide a first class organisation to manage the development of the application under the 7 cooperative principles:

1. Voluntary and open membership
2. Democratic member control
3. Member economic participation
4. Autonomy and independence
5. Education, Training, and Information
6. Cooperation among Cooperatives
7. Concern for Community

The application is a rapidly iterating fork of the popular Tusky Mastodon client, branched from version 23.0 of that application.

Pachli includes many changes from Tusky 23.0, including:

New features

• “Load more” no more. As you scroll through your feed new posts transparently load in the background
• Your reading position in a timeline is always preserved
• View trending posts and links from your server
• Use more than five tabs
• Choose from a range of accessible fonts
• A new media player component, supporting more video formats
• Mark lists as “exclusive”. Posts from accounts on exclusive lists only appear in the list, not your home timeline
• Add bookmarked posts to their own tab
• Hide “self-boosts” from your timeline

Bug fixes

• No more missing posts; Tusky and other apps can miss posts from your timeline, Pachli always shows the full timeline
• Images don’t “stick” when you zoom or swipe between them
• Search text is not deleted when you move between search tabs
• Show server error messages, making it easier to understand why an operation failed
• Filters now work in notifications

UX changes

• A visual refresh and new colour scheme
• Determine the default theme (light or dark) from your Android settings, not hardcoded to “dark”
• Move “Clear notifications” to a menu to make it more difficult to trigger accidentally
• Extend the list of available languages

Download Pachli from Google Play and F-Droid.

• Stepping back from the Tusky project
• Update #1 on “Stepping back”
• Update #2 on “Stepping back”
• Update #3 on “Stepping back”
• Update #4 on “Stepping back”
• Final entry: Update #5 on “Stepping back”

In Update #2 on “Stepping back” I alleged that some of the public statements by the Tusky project, prompted by Stepping back from the Tusky project, were lies.

It is my responsibility to present evidence for that. This is the last of a collection of posts that do that, or otherwise respond to the public statement by the Tusky team.

[!NOTE] See also Update #3 on “Stepping back” and Update #4 on “Stepping back”

You may be reasonably concerned that the following selectively quotes from the discussion. To allay those concerns the full discussion is archived at chat.md. You might want to read that first, or have it open in another window.

I have not addressed every statement made by the project in what follows. Blame Brandolini's law. Given the volume of trivially provable lies the project's contributors made in the statement they produced I leave it to you to decide how trustworthy the remainder of their comments are.

The “Conflict with Nik Clayton” section

Nik would have expected to find documentation of the decision to hire Z, but in this case would not have been able to do so because the hiring predates our current project documentation process. - Tusky Contributor response to Nik Clayton

This is a lie. I was not asking for documentation for decision making around Mike's hiring.

I was asking why the invoice showed a payment for work that was demonstrably not done.

Even if Mike's contract was for time, not specific results, the invoice should have reflected that. E.g., “X hours spent under contract Y”.

The three invoices actually said (in their entirety):

• “First invoice submission to Tusky”, #129964
• “Second invoice submission to Tusky”, #123650
• “Work on 'bookmark tab' feature (#2368); Work on 'copy hashtags into reply' (#3013); Work on 'positional substitution format' (#3297)”, #125597

When he was shown the documentation of what Z had done and why Z was paid for it, he was unable or unwilling to drop the matter - Tusky Contributor response to Nik Clayton

This is a lie. I was not shown documentation of what Mike had done.

Had I been, that's still not relevant, because my concern was not “What other work has Mike been doing?” my concern was initially “Why does invoice #125597 list work that was demonstrably not done?”, followed rapidly by “And why are these other two invoices so generic?”, then followed by “Why is the response to what should be straightforward questions so hostile?”

There are three people who had admin rights to the Open Collective project and could respond; connyduck, tak, and maloki.

Of those three, the only person who responded was maloki, and the entirety of her response pertaining to the work was the following two sentences.

It's soma, and we had an agreement that he'd be paid for the first 3 months on an hourly basis with a max ceiling. Part of their work was also offloading me, and was supposed to be working on the FAQ, but you submitted your update of it while they were working on it.

If you can straight-facedly refer to that as “shown documentation of what Mike had done”, well, you're a better dissembler than I am.

Note also that the second sentence attempts to deflect blame on to me for apparently doing work that overlapped with Mike's.

Given that my questions were not answered it is not surprising that I was “unable or unwilling to drop the matter”, and I replied:

My PR that updated the FAQ (also my first project contribution) was submitted on Dec 17 2022, and merged on Dec 22 2022. There was no public indication before then that anyone else was working on it.

The three Mike Haynes invoices on OpenCollective have the following dates and descriptions (Mike Haynes – Open Collective):

1. January 31, 2023 (“First invoice submission to Tusky”), 120964
2. February 16, 2023 (“Invoice for first half of February”), 123650
3. March 1, 2023 (“Work on 'bookmark tab' feature (#2368); Work on 'copy hashtags into reply' (#3013); Work on 'positional substitution format' (#3297)”), 125597

For the first two, what work was actually done? I can't find any PRs or issues (either open or closed) in the tuskyapp/tusky or tuskyapp/faq repositories that would match, and SomaRasu (Mike Haynes) · GitHub shows no apparent contributions.

I assume there is a straightforward explanation for this, I'd just like to know what it is.

But as and when there's a legal structure backing Tusky this will not fly. Invoice 3, in particular, looks fraudulent.

To be super clear — I'm 100% not saying it is fraudulent. This could be as simple as “Some work was intended to be done, it wasn't, other work was done instead, and the expense description was not updated”.

But we should be able to explain what that work was, and we should have processes in place so that this does not happen again.

I take a moment to note that some people have suggested that “I'm 100% not saying it is fraudulent” is a weasel-worded way of trying to suggest that something is, in fact, fraudulent.

With no other context, I could understand that point of view. However, this is not a context-free discussion. At this point I have been working on the project for approximately eight months, landed more than 150 PRs, replied to countless user questions from the Tusky account, and run the two most recent releases.

And the project's statement says they had “the intent of admin status being transitioned to him” and described me as the “primary code contributor”.

With that context it should be clear that raising any concerns like this are not an accusation of wrong doing, but an expression of concern that other people, without the relevant context, may look at the same information I did and assume fraud.

Maloki did not take it that way, responding:

Can You stop? Because let it be clear, this attitude would mean that all my contribution also isn't valid and shouldn't have been paid for because there wasn't any proof. This is an admin issue. The admins had agreements in place with people involved.

This is the first suggestion in the discussion that any of Maloki's contributions are questionable, and she raised it, not me.

I was not the only person to think like this. Charles (charlag) wrote in response to the above:

mal with you I think it was quite different. I don't know anything about this (which is probably my fault) and to me it also looks very odd.

if in your case it's a regular payment in this case it does really look like payment for work that wasn't done. I think big point of OC is transparency and this does not look good for us.

should it have been labelled differently? as in, “project management work” or similar (I assume you mean that by offloading).

I really don't think anyone is trying to put your contributions or payment into question but I agree that we should be transparent and should have a record of agreements

Charles has clearly understood the context in which I asked the original question (“I really don't think anyone is trying to put your contributions or payments into question”).

Maloki reiterates that she believes this information should not be transparent, replying to Charles:

When I'm trying to explain I really don't appreciate a fucking wall of text about how I'm clearly wrong. Like whatx the Fuck. And it's part of why we've worked on improving the process. But all these conversations aren't going to be for and open to the contributors.
And for a long while it was mostly me and Conny that had a quick chat about stuff and agreed to things. And then course corrected as needed.

During this discussion Mike writes:

I just want to say: this was work that was intended to be done, but unfortunately I couldn't get done, primarily due to my inability to wrap my head around getting a PR submitted. I did have code written for these issues, but I'm not sure if I still have them stashed or not.
I'm really sorry for any confusion I caused and for how I approached the OC invoice system. Conny had told me going forward if I were to submit any invoices that a PR(s) needed to be provided

I start a 1:1 discussion with him to see about getting any of the that he did do merged in to the project. That takes about two hours over two days, and one PR is merged the next day (more details in Update #3 on “Stepping back”). The work for the other two invoices is, to the best of my knowledge, still not complete.

Separately, I respond in the channel to Maloki.

Your explanation didn't (and still hasn't) addressed the “Why has an invoice been paid that describes work on three specific GitHub issues, when all available evidence shows that no work was done on those issues?”.

The explanation could be as simple as “Admin mistake, they worked on X, Y, and Z instead, we forgot to update the description in OC”.

This question is still unanswered.

but we as observers to the conversation feel that Maloki was generally only responding with the same harsh tone that she was being addressed in - Tusky Contributor response to Nik Clayton

I will let readers decide whether my tone was harsh. As already noted, the complete chat logs are at chat.md.

Multiple contributors had asked Nik to slow down or temporarily stop because they had no capacity to respond, for valid health reasons including hospitalization

The only people who could answer the questions authoratively were the project's three financial admins on Open Collective. They were:

• ConnyDuck (stepped down)
• Maloki (still active)
• Tak (still active, did not respond during the discussion)

Maloki repeatedly asked for the discussion to stop, saying (over multiple messages):

Can You stop? [...] This is an admin issue. The admins had agreements in place with people involved.

these conversations aren't going to be for and open to the contributors.

it's not a question that necessarily should be posed in the contributors channel

the contracts and agreements we make with people is not for public consumption, and I don't believe they have to be, which is why I was very thorns out on this question. You don't need to know any details of the agreement whatsoever besides “this was a past agreement and it got paid for”.

As already noted, Charles was the first person to reply, and replied several times during the discussion despite health issues. Charles is not an active financial admin for the project on Open Collective, and the contributions (although helpful) were unasked for, and the decision to join the discussion was their own.

Nik insisted on his solution and that it be implemented immediately. - Tusky Contributor response to Nik Clayton

This is a lie.

While the discussion was going I hastily organised my thoughts in to a strawman proposal for an expenses policy and a grants policy, and wrote them up. I had hoped that these would stop the discussion from spiralling down the drain of what had already happened, and allow us to productively focus on active changes we could make to stop it happening in the future.

They are clearly not ready to be “implemented immediately” as there are a number of TODOs, and a significant number of open questions for discussion in the grants policy.

I presented this to the group as:

[...] Since a more specific expense and grant policy might be useful, I've thrown these together for discussion:

• https://gist.github.com/nikclayton/5c4118c7f153b0a8ade904cfccde5fdd
• https://gist.github.com/nikclayton/bd1146e24e97b113c6d14f31bbd8a36c

As you'll see, plenty of open questions on both.

and

[...] The clearest explanation you will see of this is my strawman proposals for an expenses policy (https://gist.github.com/nikclayton/5c4118c7f153b0a8ade904cfccde5fdd) and a grants policy (https://gist.github.com/nikclayton/bd1146e24e97b113c6d14f31bbd8a36c).

Since we definitely have strong differences of opinion around project governance and finance issues, and since those documents set out my current thinking, could you review those, and provide feedback?

There was no feedback on these from anyone, and I never mentioned them again in the chat.

I know I've already said it, but to be clear, any suggestion that I had a solution and insisted it be implemented immediately is a lie.

By the time the week came to a close, Maloki felt the conversation had spiraled out of her ability to de-escalate - Tusky Contributor response to Nik Clayton

I had already made multiple attempts to de-escalate the discussion, including:

• Working with Mike to review and approve one of his contributions
• Suggesting clear explanations for what may have happened
• Proposing the bones of possible future policies, using what could be learned from this issue

Maloki refused to engage with any of these. As already noted, the only thing she seemed to want to do was shut the discussion down.

Mcc and Maloki were going to introduce Nik and the other contributors to L.J. within 24 hours and let her propose a process for resolving the conflict, but did not get the chance - Tusky Contributor response to Nik Clayton

I have no idea how true this is. Obviously, I had no knowledge of it at the time.

I note that Maloki's last message in the discussion (to which I did not respond) was:

We're not tone policing the issue. We're specifically asking you to stop.

This was sent 2023-08-25 (Friday) at 13:08 CEST.

Not “pause”. Not “wait until we can gather some more information”. Not “wait until I can get a mediator”.

From my perspective the discussion was over. I had raised what I thought were reasonable concerns, in the correct forum, and been given incomplete and evasive information. Clarifying questions resulted in demands that the discussion be shut down, and my attempt to redirect the conversation to a more productive “Here's how we could do things in the future” direction were ignored.

At that point further discussion or engagement seemed both futile, and was also directly contrary to Maloki's final message.

After drafting the blog post, getting some trusted friends and former colleagues to review it, and modifying it based on their feedback, I posted a brief resignation note on the contributors channel (with instructions on how to remove me from the shared project infrastructure).

The “Payments which Nik has questioned” section

We, the remaining Tusky contributors, have several issues with Nik's post. We disagree, based on the information that both we and Nik have been given, that the payments Nik objects to were inappropriate at the time. - Tusky Contributor response to Nik Clayton

I'll be (mercifully) brief here, because this section mischaracterises what I was saying, and then argues against that mischaracterisation.

So, for the nth time — I do not think that the payments were inappropriate, given the context that was provided in the discussion.

I still think:

1. The invoices did not follow the OC policy
2. Maloki's response, demanding that the discussion be stopped, that it was not appropriate for contributors, and that contributors should not have a role in holding the financial admins to account is completely inappropriate

We also object to how he mischaracterizes the positions of Tusky as a project - Tusky Contributor response to Nik Clayton

I am always happy to correct anything that I've written. If anyone from the team can (a) point to something specific, (b) let me know about you think is a mischaracterisation, and why, and I agree with you, I will correct it, and post about the correction.

and feel that he retroactively imposed future standards, which would apply should we move forward with the idea to incorporate the Tusky project, to past leadership’s decisions. - Tusky Contributor response to Nik Clayton

Again, a mischaracterisation. Also, a deflection.

First, my expectations of how a financial admin should behave when responding to questions is not related to past leadership decisions.

It may be what past leadership has tolerated — I was only involved with the project for eight months, so I can't speak to that.

Second, my standards are second to the legal agreements that the project entered in to when it signed the agreements with Open Collective and the Open Source Collective (OSC) as the project's fiscal host (yes, the the fact that two different organisations have such a close name is confusing).

Unfortunately, I can't tell what the agreement the project signed says, because the financial admins don't think it's appropriate. All I can do, as I have done, is point to where I think the project may have breached them either in fact or in spirit.

The “What Does Tusky Use Donor Money For?” section

we actively solicit people outside the project when there is work which needs to be done but which no one is available to do - Tusky Contributor response to Nik Clayton

I believe, but cannot prove with 100% confidence, that this is a lie.

[!NOTE] See also Update #2 on “Stepping back” — nikclayton

Demonstrating some proof of active solicitation of people outside the project should be straightforward.

For the past four and a half years the project has paid (Tusky · Expenses – Open Collective, and ignoring the payments to Mike which I have already noted):

• 1 payment to a Slovenian translator
• Annual payments for the tusky.app domain registration
• 1 payment to a Brazilian translator
• Payments for new artwork
• Multiple payments in 2023 to a new code contributor

The remaining payments have been to Maloki, one of the financial admins.

In those same four and a half years the project did not actively solicit people outside the project by:

• Developing a coherent expense or grants policy, despite promising to in We are setting up a way to support us! – Open Collective and Thank you very much for your donations! – Open Collective
• Posting updates to Tusky – Open Collective asking potential contributors who needed financial support to apply
• Mentioning that financial support for contributors was available in the project's CONTRIBUTING.md file or README.md file.
• Asking new contributors to the project if they needed financial support
• Mentioning the availability of financial support in the release notes, Releases · tuskyapp/Tusky (although the release notes generally mentioned the ability to donate)
• Mentioning it in the “About” section for the project on OpenCollective. At the time of writing this briefly describes the project and its features.
• Mentioning it at https://www.tusky.app, the project's public website.
• Mentioning it in the Google Play Store listing
• Mentioning it in the F-Droid listing
• Linking to anything describing the availability of financial support from the project's “Bio” fields in the Tusky Mastodon profile
• Posting from the project's Mastodon account telling people to apply for financial support (searching the account's public posts for “support”, “sponsor”, “contribute”, “grant”, “expense”, “opencollective” shows no posts describing work that needs to be done in exchange for financial support)

The only other place I could think to check is if the Tusky Mastodon account received DMs from people asking for contributions.

Obviously I don't have access to that, and even if the project was receiving those requests, the public payment history on Open Collective demonstrates that the project was generally not making payments to outside contributors.

I would be delighted to document the ways in which the Tusky project actively solicited people outside the project, should the project provide any.

But until that time, I believe the project is demonstrably, repeatedly, lying to you.

• Stepping back from the Tusky project
• Update #1 on “Stepping back”
• Update #2 on “Stepping back”
• Update #3 on “Stepping back”
• Update #4 on “Stepping back”
• Final entry: Update #5 on “Stepping back”

Have you seen Paddington 2? I realise I'm a little late to that particular movie, but it really is a delight. The whole production nails the tone perfectly, and never wavers. It would be so easy to drop an overly large knowing wink to the parents in the audience and risk breaking the spell for the kids, but they never do. They've constructed a world on film that works exactly how I imagine an 8 year old thinks the world works, and it's marvellous.

However, you're probably not here for the one paragraph film reviews, so, onward. In Update #2 on “Stepping back” I alleged that some of the public statements by the Tusky project, prompted by Stepping back from the Tusky project, were lies.

It is my responsibility to present evidence for that. This is one of a collection of posts that do that, or otherwise respond to the public statement by the Tusky team.

And if elzoido is reading, this one is dedicated to you. Only 48,567 words missing.

The “Admin Changes & Transitions” section

People stepping down

In June 2023, first Maloki, then Conny stepped down from the project.

This is partially false. Conny stepped down, Maloki did not, but planned to by end of the year.

This is confirmed by the project update posted to Some changes going forward – Open Collective (2023-07-28) which says:

As it stands right now, Conny is resigning entirely from working on Tusky, and maloki is still on in an advisory position and as an admin until the end of the year.

In July and August Maloki was still:

• Managing access to the GitHub repository
  • I know this, because I contacted all the recent contributors to confirm their GitHub usernames, and forwarded them to Maloki to be added to the repository.
• Attending Tusky team meetings (she did not attend the 2023-08-15 meeting, as she was unwell)
• Providing feedback on how those meetings were scheduled

That's all consistent with someone who is winding down their responsibilities and hasn't transferred all of them yet.

She also said (in the Tusky Contributors channel, 2023-08-17, 15:12)

And honestly atm, I'm contributing about the same amount as I always have. 😅 Minus the stress from feeling I should be doing more. 🤷‍♀️

After the meeting, when I posted some initial results from my research in to possible legal structures for the project, Maloki was the only project member who responded, saying (2023-08-21):

I think you can gather up relevant information. If you feel like it.

I think part of the problem is often that we don't have anyone with time or energy to look into these kind of things, so it's good to at least have the research

Finally, the project had three Open Collective financial admins, Conny, Maloki, and Tak.

When I asked the initial question, and through the remainder of the discussion, Maloki was the only who replied.

I did not expect a reply from Conny, he had already stepped down. I was not surprised to see replies from Maloki, as I have explained, my understanding was that she was still engaged with aspects of the project. I am surprised that there was no reply from Tak.

To summarise; Maloki had definitely announced an intention to step back. She may have been in the process of stepping back.

But to say she had “stepped down from the project” is a lie.

Transitioning responsibilities

Conny's tasks, such as releases, were handed off to Nik; Maloki's tasks were split between Nik and Andi Mcc because they volunteered. 

Partially true, but misleading. The release process “hand off” went like this:

Connyduck: – Who wants to be responsible for the next release and follow our release process? https://github.com/tuskyapp/Tusky/blob/develop/Release.md @nikclayton I think you were interested? Nik: Happy to. My schedule for the next couple of weeks is reasonably free, so I've got the time.

(“couple of weeks” turned out to be woeful underestimate on my part. The 22.0 release was rocky, but eventually successful, in no small part thanks to a handful of users who were happy to try out some test builds while I found and fixed some longstanding account corruption bugs. If you used Tusky with multiple accounts and sometimes discovered that posts from account A were showing up from account B, or you thought you were posting from account A but you were actually posting from account B, they're fixed, you're welcome.)

I was also, like some other contributors, given access to the Tusky repository so that I could approve and merge PRs from other contributors. This happened in late April 2023, long before Conny announced that he would be stepping down, and definitely not as part of any handoff.

I can't think of any other of his responsibilities that were handed off only to me, formally or informally. I am happy to be corrected on this point.

Collectively, we did add more people to the GitHub organisation so that they could help manage the queue of issues (e.g., closing them), or be added as reviewers to PRs.

I believe “Maloki's tasks were split between Nik and Andi Mcc because they volunteered” is partially incorrect. I didn't explicitly volunteer to pick up any of Maloki's responsibilities, and was never asked to.

This might be a reference to the fact that as part of managing the 22.0 release I was given the password to the @tusky@mastodon.social account so I could post information about the new beta versions and the final releases there, and respond to questions from testers.

That was part of the release process work, it certainly wasn't part of formally picking up any of Maloki's responsibilties.

The entirety of that discussion with Maloki (2023-04-26, well before any suggestion that she was stepping down, and so part of the period when posting release announcements could reasonably be expected to be part of her role) was:

Nik: Hi – do you want to post the 22-beta.1 announcement from the @tusky account, or ship the credentials to me and I'll do it? Maloki: Talk with Conny about that.

Again, this was before Conny had announced his decision to step down. And as noted earlier, there were some tasks (like adding new users to the GitHub repository) that I couldn't do, and asked Maloki to do on my behalf.

I can't speak to whatever specific responsibilities Andi picked up, except to note she definitely took over responsibility for organising and chairing the team meetings, and did so admirably.

A legal entity

The next three paragraphs:

As we tried to adjust... [...] At our August 15, 2023 contributor meeting... [...] In line with the responsibilities he'd been given...

Are broadly accurate, but also omit some colour that I think is important.

First, the need for a formal legal entity for the project was not first broached at the August 15th meeting.

This was first discussed in the team meeting of 2023-05-09, over three months earlier, as part of discussing the draft expense policy. The conclusion was to take no action at that time, but keep the idea in mind.

10 days before the August 15th meeting, after Conny had announced he was stepping back, I collated my thoughts in to Open infrastructure problems, shared it with the “Tusky Contributors” channel, asked for feedback ahead of the meeting, and added it to the agenda so we had an opportunity to make an informed decision on next steps.

Second, “assigned the task” and “responsibilities he'd been given” suggests a considerably weightier process than actually happened. During the meeting I volunteered to contact SFC and other organisations, as they had already come up in my research, and no one objected / wanted to do the work themselves.

Being added to the OpenCollective account

Around this same time, Nik was given member access to our OpenCollective account, with the intent of admin status being transitioned to him down the line.

For the record, I have no recollection of ever being told about this, asked if I wanted the responsibility, or given the opportunity to decline.

I have searched through discussion archives and private messages, and can find no reference to it.

If I have missed one I am happy to be corrected, but this statement from the project is the first time I am aware of this.