Merged
Conversation
beae153 to
726267d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
** DO NOT MERG YET***
The query was
Task: Improve rotki documentation based on real user churn feedback
Context
You are working on the rotki codebase (https://github.com/rotki/rotki) — an open-source, local-first crypto portfolio tracker and tax accounting tool. A paying user just cancelled their subscription and provided detailed UX/documentation feedback. Your job is to use this feedback to concretely improve the documentation (and flag any code-level UX issues that documentation alone cannot fix). You have checked out the documentation repository. Ask if there is anything you don't understand on what you need to do.
User Feedback (verbatim)
The user's primary use case was tax accounting and DeFi profit-and-loss calculation. Their key pain points:
1. Onboarding friction — finding the right entry point
"When I was first onboarding, it took me quite a while to realize 'Profit and Loss Report' and 'History' are the two main tabs I am looking for. Their names don't hit the 'tax' keyword, and the sidebar has too many options to browse. I downloaded, installed, and pushed myself to open Rotki multiple times before I finally 'got it' and understood what buttons to hit."
2. Onboarding friction — understanding event types and subtypes
"Once I generated PnL reports but hit unexpected numbers, I started looking into individual transactions in History. I was met with a huge list of event type and subtype options. I went to the docs first but don't remember them having sufficient detail to explain what each type does. I then looked through accounting rules — slightly more helpful (shows e.g. what's taxable) but I was confused by options like 'Count cost basis PnL', and the accounting treatments 'Swap' and 'Basis Transfer'. I ended up cloning Rotki's repo, asking AI what each option means, and writing down a personal note page."
3. Lacking custom cost basis
"I moved from a no-tax country to a with-tax country and started using Rotki then. I don't have access to certain old transaction records (e.g. FTX). For tax purposes I just need existing assets to be cost-based at market prices on country entry date. A simple solution: let users define custom cost basis for specific amounts of assets."
4. Lacking custom counterparty / smart contract for accounting rules
"Without support for defining custom counterparty / smart contract in accounting rules, all transactions not automatically picked up require manual edits — labor-intensive and error-prone."
Your Task
Work through the following steps:
Step 1: Explore and understand
/docsor similar). Map what currently exists for: tax workflows, event types/subtypes, accounting rules, cost basis handling, custom counterparties.Step 2: Identify documentation gaps
For each of the user's four pain points, produce a written gap analysis:
Step 3: Improve the documentation
Make concrete edits to the docs to address the gaps. Specifically:
A) A clear "tax workflow" entry point in the docs. A top-level page (or prominent section) titled something like "Using rotki for tax accounting" that walks a new user from install → import data → reconcile → generate PnL report. This page should explicitly mention that "Profit and Loss Report" and "History" are the two key tabs, and link to deeper docs from there.
B) A complete reference for event types and subtypes. Every event type and subtype should have:
Pull the canonical list from the codebase — do not invent types.
C) A clear explanation of accounting rule options. Specifically the ones the user named: "Count cost basis PnL", "Swap" treatment, "Basis Transfer" treatment. Each needs a plain-language definition, why a user would toggle it, and a worked example.
D) Document the current behavior around cost basis and custom counterparties — even if the feature gaps exist, the docs should clearly state what is and isn't currently supported, so users don't waste time looking for features that don't exist.
Step 4: Flag what docs cannot fix
Some of this feedback is about missing features, not missing docs. Produce a separate section at the end of your work titled "Feature gaps surfaced by this feedback" listing:
For each, suggest whether an existing GitHub issue likely covers it (search the repo's issue tracker if possible) or whether a new issue should be opened.
Constraints
Deliverables
It came back with this PR and
Deliverable 2: Gap Analysis (by pain point)
Pain Point 1: Finding the right entry point
Pain Point 2: Understanding event types and subtypes
Pain Point 3: Accounting rule confusion
treatments were not explained for users at all.
Pain Point 4: Cost basis and counterparty limitations
Deliverable 3: Feature Gaps Surfaced by This Feedback
Problem: Users moving from a no-tax to a with-tax country need to set cost basis at market prices on their country entry date. Users who lost access to exchange records (e.g., FTX) also need this.
Current workaround: Add manual "buy" trades at the desired price and date. This is tedious and error-prone for many assets.
Suggested feature: Allow users to define a custom cost basis for a specific amount of a specific asset at a specific date, without needing to create a fake trade.
Existing issues: Search the rotki GitHub issues for "custom cost basis" or "cost basis override". This is likely a new feature request if not already filed.
Problem: Accounting rules can be scoped to a counterparty, but only rotki-recognized protocol identifiers (e.g., "uniswap-v3", "aave"). Users interacting with protocols not yet decoded by rotki must manually edit each individual transaction.
Suggested feature: Allow users to define custom counterparty labels for arbitrary smart contract addresses, and use those labels in accounting rules.
Existing issues: Search for "custom counterparty" or "custom protocol" in the rotki issue tracker.
Problem: "Profit and Loss Report" doesn't contain the word "tax" anywhere. Users searching for tax-related features don't immediately find it. The sidebar has many items with no clear grouping for the tax workflow.
Suggested improvement: Consider renaming to "Tax / PnL Report" or adding a "Tax Reporting" section/group in the sidebar that groups History Events, PnL Report, and Accounting Settings together. This is a frontend UX change, not just docs.