Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
Today we are announcing the public beta of repository rules! 🎉
Repository rules are GitHub's next evolution of branch protections to help make your repositories more secure and compliant at scale.
Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place.
Creating rules
At the core of rules is the ability to define rulesets. A ruleset is a collection of rules that are enforced together. For example, you could require that all commits to a branch are signed and that those commits have two reviewers. Rulesets can also be applied to tags, allowing you to enforce rules on releases.
The ruleset page is the central place to view and manage all the rules for a repository. It shows the rules that are currently in place and allows you to add new rulesets or edit existing ones.
When creating a ruleset, you define its enforcement status as active or disabled. Active rulesets must pass for a commit to be pushed, while disabled rulesets are not enforced; they will not block a push but allow admins to craft rules before enforcing them. Enterprise Cloud customers can also evaluate rulesets: a "dry run" mode for understanding the impact of new rules before they are active and enforced.
It's also easier to target branches and tags in rulesets, with options to select the default branch, all branches, and branches or tags that match an fnmatch pattern. You can add multiple patterns to a ruleset to apply it to different branch and tag naming styles.
Viewing the rules
You can always know what rules are in place for a repository.
Anyone with read access to a repository can view its rules and what they mean. The rulesets overview is linked from the branches page by clicking the shield icon, and from a pull request, and from the output of the Git CLI when rules block a push.
From here, you can filter rules by branches or tags to understand how a rule might be enforced on your next push.
Getting Started
Repository rules are now available to all GitHub cloud customers. To get started, visit the documentation to learn how to enable and use rules. For Enterprise Cloud customers, visit the documentation to learn about organization rulesets and more.
We want to hear from you on how we can improve repository rules! Join the conversation in the repository rules public beta discussion.
When we introduced GitHub Discussions in 2020, we allowed users to mark an answer to a question in the "Q&A" Discussions category. As the feature began getting more usage, we noticed that often, the real answer to a question may live in a reply to an answer. Today, we are introducing the ability for users to mark a threaded reply as the answer to a question.
All replies will now have a button to allow the questioner to mark them as the answer.
Marking the reply as the answer highlights it and makes it clear to the reader where the real answer to the original question lives.
This feature improves the accuracy of marked answers, while also reducing the burden on users to duplicate their text to get their answer marked as correct.
For questions or feedback, please visit our community.
GitHub Importer allows you to import repositories from other code hosting platforms to GitHub.com using a UI or REST API.
Today, GitHub Importer supports Git, Mercurial, Subversion and Team Foundation Version Control (TFVC) repositories.
From October 17, 2023, we will no longer support importing Mercurial, Subversion and Team Foundation Version Control (TFVC) repositories. We're ending support for this functionality due to extremely low levels of usage.
Even without GitHub Importer, moving from these alternative version control systems to Git is simple thanks to fantastic open source tools – for more details, read our Docs article, "Using the command line to import source code".