This organization hosts the problems on Kattis — one repository per problem. The problem repositories are private (they contain secret test data and judge solutions), so what you see here is the public face: the issue tracker.
Found something wrong with a problem? We want to hear about it — all bug reports and discussion happen in issue-tracker: file a new issue.
- Start the title with the problem's short name (the id in the problem URL):
different: time limit too tight for Python - If an issue spans a few problems, list the short names in the title:
different, otherproblem: inconsistent output format. If they are too many, use a descriptive title without the prefix and list the affected short names (or describe the set) in the body. - Search existing issues first.
- Everything is fair game: broken test data, unclear statements, too-tight limits, judging oddities, typos.
- Apply the labels that fit if you're able to set them — each label's description says when it applies. Otherwise we'll add them in triage.
The tracker is public, but problem packages (secret test data, judge solutions) are not — and other people still want to solve the problems.
- No secret test data, no judge solutions, no full solutions.
- Describe the failure without spoiling more than necessary: "my solution passes samples but gets WA on a case in the second secret group" is exactly enough.
- If your report can't avoid spoilers, say so in the issue and we'll handle the details privately.
Reports are welcome as-is. If you're also willing to implement the fix in the problem package, say so in the issue and we'll follow up about next steps.
We triage, the fix lands in the problem's repository, and the issue closes when the fix merges.
If you are working on a problem in the kattis-problems organization, please
keep the following things in mind:
- There should be one repository per problem, with the name of the repository corresponding to the short name of the problem (aka problem ID).
- Within the repository, the files of the problem package (problem.yaml, data, submissions, etc.) should be at the top level, rather than inside a subdirectory for the problem.
- We would like to keep git history from other repositories if possible. The
tool
git subtreecan be useful here. - Please avoid committing large files that are not part of the problem package, such as compiled binaries, or rendered PDF problem statements.