I couldn’t when I started out doing that. But I don’t want PRs, either, so this works out for the best: I contribute a benefit and if someone forks it then I can consider merging their work unbothered by their expectations that their ‘request’ be granted.
Overlooking your repeated assumptions of my incompetence at GitHub administration, neither of the 'why not just' steps you countered with will result in the banner that says 'This project is archived', which is a key component of my intentions. (For those who overlook it, the other characteristics of archival of course still suffice; I get all three for one UX interaction rather than three!)
Which of these projects is more likely, relative to the other in its pair, to be targeted by users whose expectations are presented disrespectfully by whatever means (let's assume email) the users can discover?
1a) A project that has recent commits, but has pull requests and issues disabled.
1b) That exact same project, with the banner "This repository was archived by the owner" shown on all pages and objects within it.
2a) A project that left a work in progress unfinished six months ago, but has pull requests and issues disabled.
2b) That exact same project, with the banner "This repository was archived by the owner [six months ago]" shown on all pages and objects within it.
As one can reasonably predict, archiving when I'm not actively pushing commits turns out to be an effective way to stem the tide of jerks who otherwise pick a fight by email/irc / discord/forum / blah/blah / etc., in hopes of persuading me to commit further resources to their unpaid benefit or to finish something I don't care to work on finishing right now / this week/month / quarter/semester / year/decade / ever. It's archived, so clearly it'll never be finished, which helps enforce an appropriate calibration of expectations upon those desiring the outcome — and if I someday finish it, hooray, but no one has any plausible way to justify any expectations to the contrary, no matter how hard they wish otherwise. Thus why I recommend using archiving to remove the social pressure component of working in public on GitHub.
Of course, if you have a better solution than you've offered so far here, I'm certainly willing to consider it.
You could add your own banner that makes it clear what the status and expectations of the project are. In fact, that is probably a valuable thing to do if the project is archived too.
If you archive it, then sure user's are less likely to send you disrespectful messages by whatever means (assuming they can find such means), but they are also less likely to use it, because you have basically said "this project is abandoned". Which if you don't want users at all, I guess that's fine, but then I'm curious why you bothered to publish it publicly at all.
The thing I’m publishing is currently the only public source of that information and code worldwide. For those who need it, there is literally no competition, unless someone else opens Ghidra and reproduce my efforts over several long years from scratch. I don’t publish because I want to play numbers-go-up with the world population; I publish because I invested years of research for my own benefit and wish those who come after me to have a starting place further along than where I had to begin. Sure, it’ll benefit users, but ‘on the shoulders of giants’ only works when you publish at all.
There are only maybe a few thousand people at most worldwide who could benefit from what I’m doing, and only 1% of them might actually go looking for this. Can you imagine working as an open source maintainer on a project with a hard cap on audience size of a hundred people? Seems fine to me; I’m one of those hundred, after all :)
In the default shell? I've definitely started new django projects since 2023 and I seem to remember always having to use shell_plus for that, though maybe thats just become something I automatically add without thinking
Edit: Yep, you're right, wow thats pretty big for me
reply