The single best way you can contribute, is to share your enthusiasm about VisiData with other people. A vibrant community is essential to its sustainable development.
However, direct and forceful promotion is probably not the most effective approach for a tool like VisiData. People generally need to be exposed several times and from several sources before they will try some terminal utility they've never heard of before.
Some people are interested, but are daunted by the installation process or the interface; you can help them get it installed, and provide a few pointers to get started. Don't make it too complicated or overload them with too many features. Stick to the basics: arrow keys, quit, help, search, sort, freq table.
We also need people to mention VisiData in their forums and communities that relate to data and terminal programs. Don't spam or do a drive-by promotion; these are largely ineffective and will often be received negatively. Endorsements have more weight from people who actively post about other relevant topics; we don't want to become the "VisiData Brigade".
Finally, if you are on "Web 2.social", you can post a tweet or a tutorial or a demo or host a workshop, or anything else you think might make people interested in exploring the wonderful world of VisiData.
If VisiData saves you time on a regular basis, and especially if VisiData makes your paid work easier, please contribute to my Patreon.
If you know Python and want to augment it to suit your own workflow, you can create a loader or a plugin. In support of this, I have written a detailed api guide for VisiData.
Here are some great examples:
Without fail, these projects lead to discovering bugs and help flesh out the API, which result in design improvements in VisiData. Importantly, each issue found this way comes with real world motivations, so it is easy to explain your reasoning behind proposals and core feature requests.
VisiData is designed to be extensible, and most feature requests can be implemented as a one line command, or a tiny snippet of code to include in a .visidatarc.
If this would require changes to the VisiData core, and a reasonable design is approved, then the issue can stay open until the core changes have been made. Otherwise, in the spirit of Marie Kondo, the issue will be closed without prejudice.
Feature requests with some amount of working Python code are more likely to get attention. Design proposals with concrete use cases are very welcome.
If you encounter any bugs or have any problems, please create an issue on GitHub.
A great bug report will include:
- a stacktrace, if there is an unexpected error; the most recent full stack traces can be viewed with
Ctrl+E(then saved withCtrl+S) - a .vd and sample dataset that reproduces the issue
- a .png/.gif (esp. for user interface changes)
Some examples of great bug reports:
Check out the Plugin Authors Guide for an overview of the API.
Code in visidata/features/ or visidata/loaders/ is generally welcome, as long as it is useful to someone and safe for everyone.
Updates or additions to the core code should be proposed via an Github Issue before submitting a PR.
VisiData has two main branches:
- stable has the last known good version of VisiData (what is in pypi/brew/apt).
- develop has the most up-to-date version of VisiData (which will eventually be merged to stable).
All pull requests should be submitted against develop. Submitters will need to e-sign a Copyright Assignment Agreement (CAA) before a pull request will be accepted.
VisiData is an open-source utility that can be installed and used for free (under the terms of the GPL3).
The core VisiData utility and rendering library will always be both free and libre.
As the copyright holder, Saul Pwanson has the authority to negotiate other license terms.
By submitting changes to this repository, you acknowledge that you assign copyright to the owner of the repository (Saul Pwanson [email protected]).