We tried to communicate w/ re: ; they have outright refused to answer community questions on Copilot & took it for-profit. Copilot ignores copyleft requirements; so it's time to GiveUpGitHub.org

We can no longer in good conscience stay silent about problems w/#GitHub's products. This latest effort to capitalize on the corpus of code hosted on GitHub is merely the latest of their many ethical and moral lapses.

We call on people in positions of power in their FOSS communities to stop using GitHub and stop recommending it. GitHub, as a proprietary, trade-secret platform cannot be the singular development community for FOSS projects.

Gratis resources often entice & trap FOSS developers into a proprietary gated community — the walled garden of @GitHub. Remember: FOSS faced similar before — triumphantly. We'll do so again if take action now to protect our communities.


Over the coming months @conservancy will release guides and stories from projects that have moved away from GitHub. Let's shed light on the damage that is caused by centralizing community development on proprietary platforms.

Please join us and by visiting GiveUpGitHub.org/ and while you are still on , adding information to your README that you do not agree with GitHub's policies and monopolized place in our community.

@conservancy I might drop GitHub mirrors for new projects, but I worry that this could disproportionately cause friction among disabled users.

The main reason I currently mirror to GitHub is accessibility. The only other forge I know of that’s usable with assistive technologies is Sourcehut, my primary forge. Many feel uncomfortable with Sourcehut’s style of contribution and the other FOSS forges are severely lacking, so that leaves GitHub.

GitLab requires JavaScript for basic functionality, which itself is a little problematic from a FOSS perspective and very problematic from a privacy perspective: there’s a reason why the Tor Browser disables JavaScript on its “Safest” mode.

“the GitLab Enterprise Edition, which is provided to the public on gitlab.com, is (like GitHub) trade-secret, proprietary, vendor-lock-in software”

I agree with this statement except for the “trade-secret” choice of words. The “Enterprise Edition” is source-available proprietary software.

Some things I think you should consider adding:

Notes on CI solutions. While SourceHut and GitLab provide excellent CI, Gitea does not. Codeberg offers CI in the form of Woodpecker CI. I don’t know how good Woodpecker is from an accessibility perspective, but Sourcehut’s “builds” service is excellent.
Notes on measures taken by forges to escape vendor lock-in through the network effect (I like to call this “user domestication”). Sourcehut uses mailing lists and does not require making an account.

#POSSE note from https://seirdy.one/notes/2022/06/30/give-up-github/

@conservancy Oh, regarding vendor lock-in: I mentioned Sourcehut's email-based approach but I didn't mention that Gitea is working on ActivityPub-based federation. Edited my website's copy of the parent post to reflect that.

@Seirdy FWIW SourceHut is pretty poor accessibility-wise too. Little attention has been paid to it from what I can see.

@jookia I won't pretend that the Sourcehut accessibility situation ideal, but it's usable for the most part with assistive technologies IME. From what I can tell, it doesn't have critical issues like hidden/un-focusable items, interactive widgets that don't change states, keyboard traps, etc. The only other forge that generally passes that is GitHub.

Core functionality all works, but ancillary functionality and quality-of-life could use some significant improvements. I'll file some tickets later today; they're generally easy to fix. Some that come to mind are using additional `<nav>` elements with different labels, and naming in-page heading anchors.

#POSSE note from https://seirdy.one/notes/2022/06/30/sourcehut-accessibility/

@Seirdy it's inaccessible in ways that almost seem like they tried to make it broken: it has a hard to navigate maze-like site layout for one

@jookia Just saw your thread on the matter, updated my website's copy of that post with a link.
@jookia Ok you're def right about sourcehut's navigation issues. No way to go from a project's repo/list/tickets to the parent project page is concerning; think there's a ticket for that. I wanted to tackle it last year, I think I should give it another look.

Would love to know how I can make my site's nav better. Right now: I use labelled navigation, make the source/DOM/visual order identical, use headings and sections to break up content, and test it with multiple browser/screen-reader combinations regularly.

The only major issue I think is that I broke the first rule of ARIA for heading permalinks to make reading modes and assistive technology happy: these two agents receive different semantics for the permalinks.

I think another issue would be a lack of navigation context (e.g. breadcrumbs) for pages that aren't direct descendants of the sections listed in the navbar. My fediverse greeting (linked in my profile and "about" page) and my site design standards (linked in the footer) come to mind.

I have multiple blind readers who regularly give feedback, so I'm really interested in this.

@jookia I made full conformance with the AA level and partial conformance with AAA a goal in my site’s accessibility statement, the first sub-section of my “site design standards” page. I’ve been writing about my progress in meeting each SC in WCAG 2.2 for a while now, and plan on publishing it when finished. Here’s an excerpt of the WIP document containing every SC under Guideline 2.4:

SC 2.4.1: I use navigation landmarks and headings to bypass blocks. This includes sufficient techniques ARIA11 and H69. I also follow advisory techniques C6 and H97.
SC 2.4.2: All pages use the title element, which is sufficient technique H25. Automated checkers will flag any exceptions; I regularly crawl my entire site with HTML-Proofer.
SC 2.4.3: My source, visual, and DOM order are identical (assuming you read top-to-bottom, left-to-right). Sufficient technique C27.
SC 2.4.4 and SC 2.4.9: I’m not aware of any ambiguous link names in context; I’m open to hearing about exceptions. I try to make links comprehensible without context; this is a WIP.
SC 2.4.5: Pages can be reached through the search bar in the footer of every page (sufficient technique G161), and either my archive pages (“posts” and “notes”) listing all subpages (sufficient technique…G126 I think?), or by following in-page links on other pages (sufficient technique G125?); all posts and notes also have a next/prev link.
SC 2.4.6: I use sufficient techniques G130 and G131. I generally prefer using aria-labelledby over aria-label because the latter doesn’t translate well using machine-translation, and because I usually want assistive technologies to report content that’s similar to what sighted users see.
SC 2.4.7, SC 2.4.11, SC 2.4.12, SC 2.4.13: my focus indicators should exceed all of these requirements. They aren’t obscured, are at least 3px thick, and use both AAA contrast ratios and the APCA contrast ratios. Focus indicators for non-interactive elements (necessary for VoiceOver compatibility) use the browser default styles.
SC 2.4.8: I make correct use of aria-current in the global navigation. For subpages of each section listed in the global navigation, I emphasize the relevant section by making it a <strong> element. This represents sufficient techniques G128. As I mentioned in the grandparent post: I should do more than the bare minimum, perhaps by adding a breadcrumb list. Screen readers don’t usually pronounce <strong>.
SC 2.4.10: All sections have headings. No heading levels are skipped. Automated checkers will flag any exceptions: I regularly crawl my entire site with both axe-core and IBM Equal Access Checker.
SC 2.4.14: Not applicable; I do not have any page breaks.

Conclusion: For AAA conformance I haven’t fully met SC 2.4.9. While I do the bare minimum to meet SC 2.4.8, I should do more by adding a breadcrumb trail. I don’t think my website “fail[s] section 2.4” unless you look for strict AAA conformance, but it could certainly improve in these aspects.

@Seirdy It says clearly under benefits here:

"People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. Otherwise, they might have to make dozens of keystrokes before reaching a link in the main content area. This can take a long time and may cause severe physical pain for some users."

How have you addressed this point?

@jookia I spent a long timw evaluating skip links, and even included one at one point!

Skip links are not required for guideline 2.4; they make for one of many possible techniques to conform to it.

Regarding skipping the nav links:

1. I asked multiple blind people who read my site, and none of them used skip links; they use headings and landmarks.
2. Heading-based navigation will let you skip the navigation bar since every page follows the navigation bar immediately with a heading level 1
3. Landmark-based navigation should let you skip the navigation bar because I use a `nav` and `main` element.

Furthermore, the navigation bar is...really minimal. It's six elements in a single row, one of which is a link to the homepage. The usability gain for skipping it is far too low. It's not worth picking one of these tradeoffs:

1. dealing with hidden/visible elements that can overlap with others
2. Adding a seventh navigation link before the rest with a different functionality than the other six
3. Adding an empty space above the navbar for a persistent and/or non-overlapping skip link, decreasing the odds of the page heading showing up in the viewport (tiny mobile screens with spatial navigation, e.g. KaiOS Devices)

I personally think "skip links" make sense on a great number of sites, but they should't be cargo-culted for sites with very little skippable content that already use a semantic approach to skippable content.

@Mayana shared similar thoughts on Fedi. Let me see if I can dig up the relevant thread…

@Seirdy @Mayana

No it's fine, untag me from this convo if you're going to have logic like that

@jookia My bad, sorry for that callout. Just recognized your username. :ms_facepalm:

@Seirdy I don't recall talking about this specifically, so it must've been some time back (in which case the auto-post-delete took care of it). I could write something up again in the morning, but for now let me just say that I entirely agree with all of this.
Also, this may be of interest, as it directly asks about skip links: webaim.org/projects/screenread
Edit: Keeping for clarity, but untagging the other participant as requested.

@Seirdy @jookia

Is there a good guide anywhere on what to do, and not do, to make software accessible?

@conservancy holy god damn i wish the whole emacs community development ecosystem would ditch github

@conservancy I sent an email off to the mailing list, but it's extremely frustrating that you're not explaining how moving to open source projects will exclude people with disabilities. Why would you omit that?

@conservancy I mean I guess it's no surprise given your website hasn't put much work in to this topic either, with lack of skip links and keyboard-inaccessible menus. Sigh.

@jookia @conservancy I don't know the development model for Gitea, but working on that project seems like the way to go.

@clacke lmao what? but its only for elites... dont joke, okay? i know you give only plain sites and thats all from you :/

LB: I moved all my projects except Leiningen off github a couple years ago, and now I'm looking into moving that as well. a read-only mirror will probably remain on github for a few years to ease the transition, but I'm looking at @codeberg as the new home for my last remaining github-hosted project once I can get the CI setup switched over.

if you've looked at moving off github in the past and ended up extremely unimpressed by the janky ui and bugs of gitlab, i don't blame you. but please give codeberg.org and other gitea sites a second look; they are head and shoulders above gitlab in usability and stability.

@technomancy i'm curious about the vibe of an actual shared gitea instance. a solo one has been nice enough, but aside from linking people to my published code there's not *that* much utility in a code forge no one else is using...

@technomancy (this is why i keep hoping for federation in gitea, but at any rate i maybe should give things like codeberg a look.)

@brennen @technomancy (federation feels like the wrong model for code repos -- what I want is to be able to identify myself to the repo in a consistent way when I write issue reports or want code review on a branch. being able to slap in a g*th*b or g**gle account to log into a gitlab instance handles this almost ok, but less centralized identity providers would be better)

@brion @brennen it's true that federated login is the main blocker and provides 90% of the benefit.

replicating the data out to other places feels like it could have positive implications for offline use, which has long been a sore point for issues, but I haven't thought that thru.


(i don't think federation at the forge / review tool level is exactly what i *want*, but it seems like it could be a reasonable way to spackle over parts of what feel to me like the core problem:

we have an effective monopolist in the code forge space because acceding to total centralization was the easiest way for users to get a bunch of stuff that the allegedly-distributed VCS's data model & interface can't accommodate, even though it's super useful stuff.)

@brion @technomancy (this is just my "reviews & annotation should be modeled in the vcs" rant again plus my "holy shit does git's interface suck" rant again i guess.)

@brennen @brion right i mean none of this would matter if any of the fossil-type efforts for git had actually panned out

@technomancy @brennen @brion well, they've panned out to the extent that multiple ones are good enough to use. (I use one; my users may grumble, but they do too.)

But how to get from that point to them being commonly used? Since MS has captured the entire mindshare to the point that even people who don't use github go looking for a clone, rather than a distributed solution.

@joeyh @brennen @brion if that question had an easy answer, we wouldn't be having this conversation. =)

for me in this case it's more important to get off github and have my contributors actually follow than to have the optimum workflow I prefer, so I'm willing to put up with the github-cloned stuff. one step at a time.

other projects (like #fennel) are more fringe and likely to attract people who are ok going outside their comfort zone, and that's where I use the mailing list+patches workflow. but I still haven't tried any git-integrated issue trackers.

@technomancy @joeyh @brion this is me duly telling myself that i'm going to experiment more with all of this and be less beholden to some vague notion of opportunity cost in doing so.

@technomancy @joeyh @brennen @brion honestly a TODO.org in the root of the repo goes an awfully long way

@joeyh Sorry to bug you (get it? :D) but which fossil-style project-management-in-repo solution for git are you using? And which ones do you consider good enough to use?

I'm planning to try git-bug, but I'm waiting for their next release to un-break the GitHub bridge, so I can extract my issues on my way out. github.com/MichaelMure/git-bug

I didn't post the link for some time, so in case someone hasn't seen it dist-bugs.branchable.com/softw… is a list of pretty much All Of Them with some links and brief descriptions.

@skyfaller @joeyh

@technomancy @codeberg Does your list of projects ever end? I'd known you as Cool Mastodon Dude for weeks before learning you ran Fennel, then several more months before I learned you were behind the Atreus keyboard, and I've now been following you for over a year, possibly years plural, before learning you did Leiningen

This is like the Russian Stacking Doll of code productivity and smash hit projects

@klardotsh haha well if you go any further back you'd have to start scraping the bottom of the barrel. I had a few hundred users on the Emacs Starter Kit but that honestly wasn't very good. before that it was all Ruby stuff which is best forgotten.

now that I got CI working on codeberg, I'm ready to proceed with moving Leiningen off github for #giveupgithub

I've opened an issue here to gather feedback from the community; please chime in if you're a Leiningen user and you have thoughts about where to move: github.com/technomancy/leining

@technomancy thank you for raising awareness, I'm trying to decide for my own projects where to put the ones I want to be publicly available. Torn between self-hosting Gitea or Codeberg/Src.hut...

@conservancy Some feedback for you is to act as 1 of the orgs that pushes for source-code repos to support ActivityPub the same way Mastodon is federated, that way more people can host their own instances and interact across instances.

Right now there are only 5 viable general options:

gitlab.com (aggressive auto-ban)
www.opencode.net (same issue as gitlab)
sourcehut.org (prohibitively expensive)

Hope this feedback helps.

@conservancy i can say moving from github to codeberg was very painless! The gitea migration tools are excellent

@huntra @conservancy yeah and Gitea's upcoming federation will probably push more users to leave Github in favor of Gitea. 🙃

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!