[RFC] Zen of py3status

[ultrabug]

Following up on #1566 I'd like to propose a short yet good enough zen to allow us to create a frame for our decisions.

If I'm missing something important, feel free to propose it.

This is meant to be added to the py3status philosophy!

efficient and simple defaults

remember the philosophy:

no added configuration file, use the standard i3status.conf

we like py3status because it's a drop-in replacement of i3status
i3 users don't expect fancy and magical things, they use i3 because it's simple and efficient
keep configuration options and default format as simple as possible

it's not because you can that you should

on modules, expose things that you WILL use, not things that you COULD use
on core, make features and options as seamless as possible (lazy loading, sane default, no strong requirements)

good enough is good enough

strive for and accept "good enough" features / proposals and keep discussions on this topic only
you can always iterate further after it's merged IF it's worth it

one feature / idea at a time

trust and foster iteration with your peers by refraining from digressions
keep discussions focused and easy to get into

modules are responsible for user information and interactions

that is what's written in the bar and its behavior on clicks etc

core is responsible for user experience

core features and configuration options should focus on users overall experience
things that are related to the actual overall output of the bar are handled by core
smart things overlaying modules themselves also end up in the core

rely on i3status color scheme

no fancy colors by default, only i3status good/degraded/bad
if we want to provide enhanced coloring, this should be a core feature

rely on the i3bar protocol

what's possible with it, we should offer, no less no more

[maximbaz]

Agree on all points, this is a good summary of #1566. Could you please also comment on the topic of breaking changes, consolidating modules (I'm thinking about examples like the new update module which replaces all of the existing *_updates modules), rewriting modules from scratch and cleaning codebase of deprecated options when major version changes?

[ultrabug]

@maximbaz I think most of those answers are contained in my version 4.0 point of view #1584

[ultrabug]

https://py3status.readthedocs.io/en/latest/contributing.html#zen-of-py3status

For further modifications, we welcome PRs ;)