// For parents, teachers & administrators
Who's watching this, and what it costs.
Panther CS is a proposed student-run computer science club at O'Fallon Township High School. Students build and maintain a website with a real page for every club in the school. This page answers the questions an adult should ask about that before saying yes to it.
// In plain language
What the club actually does.
OTHS has roughly a hundred student organizations. About six of them have a page on the school website; the rest are a name on a static list. That means most clubs here are invisible to the freshmen who'd join them and the parents who'd support them.
The club's project is to fix that: a directory with a real page for every organization in the building, designed, written, and built by students. It starts with a small pilot of two to five clubs, and grows from there.
Students learn web development while doing it, using The Odin Project — a free, open-source curriculum. Meetings run an hour a week after school — part working session, part guest speaker, part a room to learn in with other people. Membership is free, there are no dues, and no student needs their own computer.
How membership works, and what it asks of a student
There are three ways to be in this club and only one of them asks anything. Most members drop in: they come to the weekly meeting, work through a free curriculum in a room with other people doing the same thing, hear from a guest speaker every second or third week, and owe nothing in between. No assignments, no deadlines, nothing graded.
The two committed tracks — building, and design, writing & photography — are the ones that publish to the live site. Those cost about two to three hours a week including the meeting, and the club says so in writing before a student joins rather than after. Entry is by asking: no audition, no prerequisite course, and no requirement to already know how to code, because requiring one would hand the whole thing to the students who arrived knowing it.
No student is removed from this club for falling behind. A sport, a job, a hard semester — a member says so, takes a declared leave, and keeps their seat. If it keeps not working they move back to the open track: still in the club, still in the room, with the door back open on the same terms as anyone else. Two officers handle that conversation rather than one, it happens privately, and the club's stated position is that moving between tracks in either direction is ordinary and not a judgment.
Who supervises it
A faculty advisor, who is present at meetings, named on all formal correspondence, and has read access to the repository where everything the club publishes is recorded — every change, every review, permanently. The seat is filled; the club is not looking for one.
- Faculty advisor
- Confirmed
- Meetings
- Weekly after school; day and room announced in September
- Student officers
- Elijah Flor, President · Wyatt Brown, Vice President — both Class of 2028
- Questions
- A club address is being set up — check back shortly
- In person
- Panther Connects, at the activity fair
// Publishing under the school's name
Nothing goes live without a review.
Students on the club's two committed tracks contribute to a published site, and beginners are among them from early on — there is no audition and no prerequisite course, because requiring one would mean only the students who already know how to code ever get to build anything. That's deliberate, and it's workable because of one control, described below, that the club treats as a requirement rather than a formality.
The review gate
- Every change is proposed, not published. A student's edit becomes a pull request: a proposal that sits outside the live site until someone approves it.
- A trained member reviews it before it merges. Not a rubber stamp — a real read, against a written checklist.
- Reviewers are plural on purpose. Two additional students are trained by October, because a review gate that bottlenecks on one busy person is a gate that gets skipped.
- The advisor can see all of it. Every proposal, every review, every change, permanently, with names and timestamps attached.
- Anything published can be reverted in seconds. Every version of the site is kept.
What can and can't go on a page
A written content policy governs what gets published under the school's name, and the structure enforces most of it: students fill in fields on a template, they don't hand-write pages. That bounds what can go wrong to what fits in a description box. Club pages are published with the club's agreement, and the school's website team is consulted before the directory carries meaningful traffic rather than after.
Quality
Pages go live as they're finished rather than in a batch. Each one is reviewed before it publishes, and the pace is set by what the students can do well rather than by a date — which is deliberate, because a deadline is how student work ends up public before it's ready. The club starts with a pilot of two to five clubs to prove the template and the review process, and scale comes after that, not before.
// Safeguarding
Where students talk to each other.
The club needs somewhere to ask questions between meetings. A space operating under the school's name where minors talk is a responsibility, so the conditions are written down rather than assumed. Here is where that stands today, including the part that isn't settled yet.
- District policy governs the platform. The club uses Discord for collaboration between meetings. It has not yet been cleared with the district, and no invite is published until it is — if the answer is no, the server comes down and the club moves to whatever the school already sanctions.
- The advisor decides his own role in it. Whether the advisor holds administrator access to the server is his call, made with him rather than around him — and it happens before the server is used for anything that matters.
- Club business happens in channels, never in direct messages. Written into the rules on day one.
- Conversations about a member's standing are never one-to-one. Any conversation about someone's participation — including asking them to step back from a track — involves two officers, never one.
- The rules bind officers exactly as much as members, and they're posted rather than assumed. Consequences run from a warning through removal from the club and, where warranted, disclosure of chat history to the school.
- Server rules mirror the school's code of conduct. The OTHS Student Handbook applies in full, on top of them.
- History is kept. Nothing is set to auto-delete, so there is always a record.
Artificial intelligence
The club buys no AI tools and hands none out. There is no tier of access that some members get and others don't. Members may use the free tools available to any student, for learning and for help reviewing their own work.
Everything pushed to a club codebase has to be explainable. A reviewer can ask any member to walk through their own change in a meeting, and "I don't know, it generated it" is a failed review. That rule is the club's actual protection here, and it is enforced by the same review gate described above rather than by an honor system.
What a student does on their own coursework is governed by the school's academic integrity policy, not by this club.
Student information
The interest form on this site asks for a first name, grade, school email, which part of the club interests you, and whether you've coded before. It goes to a spreadsheet the officers and the advisor can see, it's used to tell people when meetings are, and it isn't shared with anyone else.
// The ask
What this costs the school.
Nothing, in year one. There is no budget request, no student activity fund account, and no dues. Every tool the club depends on is free for students, and that is a design decision rather than a happy accident — a club that needs money is a materially harder yes, and dues would price out exactly the students this is for.
What we do ask for
- A room, once a week, after school.
- Web access on school devices to two sites: github.com, where the work lives, and theodinproject.com, the curriculum.
- Nothing toward the website. The site runs on a domain the club pays for — about $15 a year — and free hosting. You are reading it on that domain right now. If a school subdomain would ever be useful, that's an offer rather than a request.
Nothing gets installed on district devices
Students write code in GitHub Codespaces, which runs entirely in a browser tab. A school Chromebook is a complete development environment with nothing installed, no admin password, and nothing for IT to maintain. It also means every student works in the same setup, so the members who own a laptop don't quietly become the real developers while everyone else watches.
Built to outlast its founders
- The domain, hosting, code, and accounts move into club-owned accounts rather than a student's personal login, with two officers holding access. A club product living in a graduating senior's account dies quietly the following fall. The domain is founder-paid today, and moving it is the club's own first housekeeping job — it happens before the first club page ships.
- Underclassmen are in the officer group from year one, so trained leadership exists before the founders graduate.
- The tools are boring on purpose. Plain text files, standard web technology, and full documentation in the repository, so the student running this in 2028 can read it, run it, and grow it.
The short version.
Students build a real website for every club at OTHS. An adult sees everything, nothing publishes without a review, it costs the school nothing, and in two years there is either a working directory at a real URL or there isn't — which is a much easier thing to judge than a plan.