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.
To read more about this effort see our blog post at https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/
@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.
“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.
@Seirdy FWIW SourceHut is pretty poor accessibility-wise too. Little attention has been paid to it from what I can see.
@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 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?
@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: https://webaim.org/projects/screenreadersurvey9/
Edit: Keeping for clarity, but untagging the other participant as requested.
@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.
@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 https://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)
(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.)
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.
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.
@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. https://github.com/MichaelMure/git-bug/
@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: https://github.com/technomancy/leiningen/issues/2800
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!