argotorg / argotorg/solidity

Use a format that allows line breaks for the list of known bugs

Open
#16,968 4 comments 0 reactions 0 assignees View on GitHub
documentation :book: low effort low impact nice to have
Dominant language
C++
Stars
25.7k
Forks
6.2k
Avg merge
2d 19h
Merged PRs (30d)
29

Description

## Abstract
Bug descriptions in [`bugs.json`](https://github.com/argotorg/solidity/blob/develop/docs/bugs.json) are long but have to be squished into a single line due to the limitations of JSON. This makes them hard to both read and write. It's especially inconvenient to make small suggestions in review, because it's always a huge diff and github for some reason does not even highlight changes in it.

We need to do something to allow writing them with line breaks. One way to achieve that is to use a different format and add a script that produces `bugs.json` from it automatically.

## Possible solutions
We could put each description in a separate Markdown (or RST) file, which would allow more formatting, including line breaks between sentences. This would be very simple, but the downside is that it would separate the description from other fields making it harder to browse through the list.

Another option is to convert the list to YAML. The downside here is that this adds a dependency on YAML tools - tools for processing JSON are much more widely available.

## Backwards Compatibility
Fully backwards compatible as long as the generated `bugs.json` keeps its current format. The main concern are tools that process the list, e.g. Etherscan, which displays a list of known bugs on contracts.

Contributor guide

Open the contributing guide

Research direction

Start with docs/bugs.json and review how the known-bugs list is currently maintained and consumed. Compare a line-break-friendly source format and a generation step, then verify that the generated bugs.json retains its current format for external tools such as Etherscan.

Written by the indexing model from the issue text.

Assessment

Tech stack
json, markdown, yaml
Domain
documentation, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.