@freemo
That said, where do I get
plex-sans.sty?

@tatzelbrumm no clue what style sheet that is off hand.

@freemo,
In TufteReport.cls,
just add a few %, like,

%\usepackage[sfdefault]{plex-sans} % Use IBM Plex Sans as the sans font and make it the default
%\usepackage{plex-serif} % Use IBM Plex Serif as the serif font
%\usepackage{plex-mono} % Use IBM Plex Mono as the mono font

and things compile well elsewhere
(after sorting out the BibTeX stuff)

Added benefit:
The font conforms to
the Potrzebie system of weights and measures.
https://polaris93.livejournal.com/2046896.html

@tatzelbrumm oh, all those packages should be installed as part of you tex install.. but you may need to pick a pretty aggressive install package.. most platforms have something like texlive-full that has everything you need.

The server itself will compile the pdf for you when you submit a change by the way.

@tatzelbrumm as we make changes on git it will automatically compile it and publish the new pdf here:

https://ufoi.gitlab.io/constitution/united_federation_of_instances_proposal.pdf

you can also run gitlab-runner locally on the project to compile it locally

@freemo
ok, I cloned the repository,
got rid of the IBM plex font directives, and can edit locally.

What's the procedure to push contributions?
Clone??
On bitbucket???
github????
gitlab.com?????

@tatzelbrumm create a topic-branch (once just for you), push it there, go to the web-ui create a merge request off of it... select the option to delete topic branch once merged.

@freemo
ok, so far I can't push from my local repository.
Do I need to create a fork on gitlab to be able to send a merge request?
Should I create one branch per merge request or will one branch for several pull/merge requests suffice?

@battaglia01 content creators can not use this platform to advertise anymore than others... with that said its ok if they share their content so long as they dont try to sell it here (such as including purchase links).. We try to conside rit on a case by case basis but generally if your posting with the intent to make money, content creator or not, its a no go. but you can talk about things you make money off of indirectly.

Unlisted is one of the privacy options on a post (see the little globe, hit that when writing a post). It means that only people who go to the post and followers will see it. It wont show up in the local or federated timelines.

This is likely very damaging to the furry demographic that usually are artists where their primary income is through things like art comissions. I think that this policy will make furry instances unlikely to participate. I can certainly see it being fine to agree to content warnings, tagging of such content and allow different servers in the federation decide if they want to filter that content out or not.

@Ryle Sorry I had a brain fart, I thought for a se3cond I was talking about QOTO and not the UFoI

I take back what I said and agree with @battaglia01 that an exception for content creators should be allowed in the UFoI's constitution. QOTO will remain non-commercial however.

Hey do you want to try to create a merge request with your proposed change (either of you can)... also add yourself to the contributors if you arent already there.

Sure, I can do a proposal and merge request. The proposal.tex is the file I should be modifying?

@Ryle

Yup that is the one.

@battaglia01

@freemo @Ryle yes I meant this "UFOI" thing. There are now a bunch of famous or quasi famous celebrities on Mastodon, including STEM people - if John Baez, Eugenia Cheng, Sabine Hossenfelder, George Takei, etc write a book I would want them to be allowed to post a link for me to buy it... They probably will anyway. Many of these people barely know how to use Mastodon and I doubt they even know what unlisted means or how to do it.

Of course QOTO can have its own rules for its own instance if you want it to be non-commercial, but I don't think it should be a federation wide rule, also for the reasons Ryle said above. I'm not sure if my suggestion would be just to get rid of that rule entirely, or if there is some way to reword it. Maybe I will leave that to Ryle as I am still pretty new here

@battaglia01

Maybe we want to remove the whole "no-commercial" rule entierly.. youve convinced me of that personally.. Can you throw up an issue or merge request and ill be happy to back you up as we are in agreement.

@Ryle

@freemo @Ryle OK sounds good. I saw Ryle was about to make a merge request already so maybe will leave that to him

@battaglia01

Was he?

@Ryle

Yes; I am working on a proposal now. Although, my proposals is more about changing it to a tagging requirement than removing it all together. This gives instances operators the maximum flexibility to filter or not filter without feeling the need to defederate.

Merge request is here, can discuss on ticket - https://gitlab.com/ufoi/constitution/-/merge_requests/1

@Ryle

Wonderful, thank you!

@battaglia01

@freemo @Ryle

I think most of the changes are good. I'd probably just ditch the commercial requirement entirely. If some individual instance wants to have that requirement then that's alright, but I don't think it should be a federation-wide rule. Like you were saying, there isn't much for artists on here to do except for promote their stuff, which should probably be encouraged if anything. Instances primarily for artists should be permitted to let their artists post w/o special tags if they want to. Same with STEM authors promoting books.

My only concern behind this is if some instances would rather not federate if they couldn't filter it out. I personally don't mind it being removed otherwise.

@Ryle

You mean like filter out a whole instance?

@battaglia01

Hypothetically, lets say you run an instance that is doesn't allow any commercial activity posts. If your choice with federating with another set of instances becomes do not federate to stop content you don't want.

Or, in my proposal, just filter out unwanted messages based on hashtags.

@Ryle

This is actually sort of where coalitions come in. Their job can be to document subsets of the rules and provide lists which users can use.. for example if we decide to allow nudity then maybe as a compromise we can create coalition whose job it is to document instances that allow different types of nudity and then users can use that as a block list if they want or even as an allow list.

@battaglia01

My only counter argument to this, is tagging makes it possible for more liberal/open instances to federate with very restrictive instances, without the instance choosing to silence the entire instance in the best case scenario when tags aren't provided.

@Ryle

If MRFs were a think on mastodon (someone correct me if im wrong but they arent) then id agree with you.. but I dont think it would work too well for the mastodon side.

@battaglia01

I was sure I saw this before in Mastodon too (although, maybe that was in the user settings); I'll have to install 4.0 and take a look at the admin panel.

suggestion: make (in UFoI) tagging *recommendations* rather than *requirements*. instances can them bump the recommendations to requirements if they so wish

also consider that CWs are not available throughout the fediverse; maybe recommend hashtags for such tagging (maybe you're already doing that?)