We tried to communicate w/ #GitHub re: #Copilot; they have outright refused to answer community questions on Copilot & took it for-profit. Copilot ignores copyleft requirements; so it's time to #GiveUpGitHub https://GiveUpGitHub.org
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 #GiveUpGitHub by visiting https://GiveUpGitHub.org/ and while you are still on #GitHub, adding information to your README that you do not agree with GitHub's policies and monopolized place in our community.
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.
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/
@Seirdy FWIW SourceHut is pretty poor accessibility-wise too. Little attention has been paid to it from what I can see.
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
@Seirdy To be specific both Sourcehut (and your website) fail WCAG section 2.4 https://www.w3.org/TR/WCAG22/#navigable
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.
@Seirdy Basically read that WCAG section I mentione
@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 Why didn't you add a skip link?
@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?
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 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.
@jookia @conservancy I don't know the development model for Gitea, but working on that project seems like the way to go.
@jookia @conservancy I have used Codeberg and should move more over there.
@passthejoe @conservancy Codeberg is just as broken
@conservancy Are there good (and gratis) alternatives to GitHub actions?
@ArneBab Gitlab CI maybe? @conservancy
@loveisgrief @conservancy @ArneBab
@clacke lmao what? but its only for elites... dont joke, okay? i know you give only plain sites and thats all from you :/
@conservancy Thank you for your commitment and patience.
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.)
@technomancy
@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.)
@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. https://github.com/MichaelMure/git-bug/
@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: https://github.com/technomancy/leiningen/issues/2800
We can no longer in good conscience stay silent about problems w/#GitHub's products. This latest effort to capitalize on the corpus of #copyleft code hosted on GitHub is merely the latest of their many ethical and moral lapses.