Skip to main content
RootBadger RootBadger

RootBadger Help

RootBadger is built around topic-based discussion, old-school group names, threaded replies, readable posts, and a slower community rhythm. This page explains the main parts of the site and how they are meant to work.

Getting started

The easiest way to use RootBadger is to pick a few groups, subscribe to the ones you care about, and check your home feed for unread activity. Groups are discussion areas. Threads are topics inside those groups. Replies stay attached to the thread so the conversation remains readable.

RootBadger is not trying to be an algorithmic feed. You will get more out of it by choosing subjects you actually care about, starting threads with clear titles, and replying where you can add something useful.

Accounts and identity

Your username is how people find your profile and recognize your posts. Pick something you are comfortable using in public discussions. You do not need to use your real name.

Email is required for account access and verification, but your real account email is not meant to be shown publicly. When you post, RootBadger can show a public posting identity based on your profile settings. You can hide or use a fake public email/from value there if you do not want a real address attached to discussion posts.

Email verification helps reduce spam and account abuse. Some features may require a verified address because RootBadger needs a basic trust signal before allowing higher-friction actions.

Groups

Groups use the rb. prefix to make it clear they are RootBadger groups, not official Usenet groups. Examples include rb.comp.lang.python, rb.comp.programs, and rb.alt.politics.

A good group should have a clear purpose. The group charter should explain what belongs there, what does not belong there, and whether the group is open or moderated. A clear group is easier to subscribe to, easier to moderate, and easier for new users to understand.

Subscribing to a group adds it to your sidebar and home feed. If a group has unread activity, RootBadger shows a count beside it. Inside the group, threads with activity can show their own unread count so you can tell which topics changed.

Writing a charter

A charter is the plain-language purpose statement for a group. It tells people what the group is for, what belongs there, what does not belong there, and how the group should be moderated. A good charter prevents confusion before it starts.

The best charters are specific without being stiff. They should be clear enough that a new person can decide whether their post belongs in the group, but not so complicated that nobody wants to read them.

A group may also have a short slogan: a one-line Usenet-style tagline that gives the group some personality. Keep slogans brief, readable, and safe for public display; the charter should still carry the serious scope, rules, and purpose.

When creating a group, try to answer these questions:

  • What is this group about?
  • Who is it for?
  • What kinds of posts are welcome?
  • What kinds of posts should go somewhere else?
  • Is the group open, moderated, or tightly focused?
  • Why should this group exist instead of using a broader existing group?
Example charter RootBadger group: rb.comp.programs.announce

Charter

rb.comp.programs.announce is for announcements about software releases, tools, utilities, libraries, scripts, services, and related project updates. Posts should help readers quickly understand what changed, who the software is for, where to find it, and why it may be useful.

Appropriate posts

  • New software releases and version updates.
  • Security, maintenance, or compatibility announcements.
  • Calls for testers, contributors, translators, or documentation help.
  • Clear project introductions for tools that are ready for public use.

Posts that belong elsewhere

  • General programming questions should go to a language or programming discussion group.
  • Long debates about software design should move to a discussion group.
  • Repeated advertising, affiliate links, misleading claims, and spam are not welcome.

Posting guidelines

Use a clear subject line. Include the project name, version if relevant, supported platforms, a short summary, and a trustworthy link. Be honest about whether the project is commercial, open source, experimental, abandoned, or actively maintained.

Moderation approach

This group may be moderated to keep announcements readable and reduce spam. Moderation should focus on topic fit, abusive behavior, malicious links, and repeated promotional flooding. Moderation should not be based on whether moderators personally like a project.

Rationale

Software announcements are useful, but they can overwhelm broader discussion groups. A dedicated announce group gives releases and project updates a proper home while keeping general programming groups focused on conversation, questions, and technical discussion.

Posting and replies

A thread starts with a post. Use a specific subject line so people can understand the topic before opening it. Replies belong inside the thread and should respond to the post or reply they are under.

Reply boxes are hidden until you choose to reply. This keeps threads compact and easier to read. Replies may be indented so it is easier to see who responded to whom, while still keeping the thread in posting order.

Headers are available where useful, but they are hidden behind a control so they do not take over the page. Headers are mostly for people who care about message details, posting identity, client information, and threading metadata.

Moderation controls

Some thread controls are only available to group moderators and site admins. Regular users may see a grayed-out Lock or Unlock button so the feature is visible, but it cannot be used unless the user has permission for that group.

Lock prevents new replies in a thread. If a thread is already locked, the button changes to Unlock, which allows replies again. The mouseover tooltip explains what the button will do.

Locking is meant for moderation situations such as spam bursts, heated threads that need to cool down, duplicate topics, or threads that should remain readable without collecting more replies. It should not be used just because a moderator dislikes an opinion.

Other actions have different purposes. Report spam sends a report for review. Cancel is for moderators/admins to request or perform removal of spam, abuse, or clearly inappropriate content. Site admins make the final call when a post needs stronger action.

BurrowCraft

BurrowCraft is the art of posting well: clear titles, clean grammar, proofread thoughts, useful structure, and a professional voice. A BurrowCrafter treats a post like a small performance piece: prepared, readable, and worth another person's time.

If you want to improve how your posts land, read the full guide: How to BurrowCraft.

Markdown and formatting

RootBadger supports Markdown for posts and replies. You can use paragraphs, links, lists, quotes, inline code, and fenced code blocks.

For code blocks, put three backticks on a line before and after the code. This is useful in programming groups because indentation and line breaks matter.

```
def hello():
    print("Hello from RootBadger")
```

Raw HTML is escaped for safety. That means people can talk about HTML or scripts without turning posts into executable code. This is intentional and helps protect readers.

Notifications

Notifications tell you when someone replies to one of your posts or mentions your username. The notification badge counts unread notifications only.

Opening a notification marks that specific notification as read, so the count should drop one at a time. The Mark all read button is still available if you want to clear all current notifications at once.

Read notifications do not stay in the main list forever. RootBadger keeps unread notices visible, but read notices are limited so the page does not become a giant archive.

Private messages

Private messages are separate from public posts. Message email notifications only tell you that a new message exists. They do not include the message body, so you need to visit RootBadger to read and reply.

This keeps private message content out of email where it can be forwarded, indexed, or stored by outside mail systems. If you receive a message, use the Messages area to open the conversation.

Standing

Standing is RootBadger's trust and participation signal. It is not karma, and it is not meant to turn discussion into a popularity contest. Standing Points represent useful participation, clean behavior, good reports, approved group work, and other positive community actions.

Standing Levels are badger-themed: Kit, Tunnel Digger, Burrowhand, Thread Badger, Charter Badger, Watch Badger, Elder Badger, and Root Badger.

Higher Standing may eventually mean less moderation friction, stronger report weight, and possible eligibility for future steward or moderator roles. It should not give anyone special control over ordinary discussion.

Image uploads are one place where Standing is used as a soft safety requirement. To attach images to posts, replies, or messages, an account currently needs at least 10 Standing Points, which is the Kit level. At 100 Standing Points, image uploads do not normally require admin approval after validation. Images still appear as click-to-view attachments and may be removed, rejected, or hidden if they violate site rules.

Useful marks are quality signals, not Reddit-style upvotes. Only trusted users can award Standing through useful marks, and the system uses caps and abuse checks to reduce point farming.

Read the Standing details

Invite links

Your profile area can provide a personal invite link. If someone joins through your link and verifies their email, you can receive a small Standing award.

Invite points are intentionally small. The goal is to encourage real community growth without creating a spam incentive. Invite awards are logged and can be reversed if the system is abused.

RSS feeds

RootBadger supports read-only RSS feeds so users can follow public posts in their preferred RSS reader. RSS is for reading only. It does not allow outside users, servers, or feed readers to post into RootBadger.

Available feeds include recent public posts, public group feeds, public thread feeds, and public user feeds where profiles are public. Private messages, private emails, hidden posts, deleted posts, moderation notes, IP addresses, and admin-only content are not included.

/feeds/recent.xml /feeds/groups/rb.comp.lang.python.xml /feeds/threads/{thread_id}.xml

Mobile app

The Android app is a native RootBadger client. It is not meant to be just a web link. It connects to RootBadger through the app API for login, groups, threads, replies, messages, profile details, subscriptions, and other app features.

The app is still being tested before Play Store release. Private downloads are only shown to approved accounts while testing is ongoing.

Privacy and safety

Public posts should be treated as public. Do not post private information you would not want others to see. Discussions can get heated, so think carefully before attaching a real name or real public email address to your posting identity.

RootBadger escapes unsafe HTML and sanitizes rendered content to reduce the risk of malicious code in posts. Security still works best in layers, so moderation, rate limits, server protections, and careful output handling all matter.

If you see spam, abuse, malicious links, impersonation, or other bad-faith behavior, report it rather than escalating the argument.

Settings

Profile settings control your public profile details, posting identity fields, signature, direct reply notification preference, image attachment preference, and invite link area.

If something looks wrong, check settings first. Many display choices are controlled there so you can decide how much identity information you want to show.

Create an account