Permalink
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
101 lines (71 sloc) 3.64 KB
# Contributing
At this early stage we're going a bit fast and loose. There are currently no processes involved contributions.
If you'd like to hack on purebred, either pick an issue from the backlog and
signal with a comment that you'd want to work on it. Most of the issues are very
high level and need clarification when it comes to implementation details. So
communication is the key here rather than hacking away.
## Hacking guidelines for purebred
- do not use hs-notmuch message methods that open file descriptors
- optics are your friend
- use `view`, `review`, `set`, `over` and so on instead of the
infix optic functions from lens
- use explicit import list or qualified imports
- no perf optimisations without measurements (preferably in the commit
message)
- use the weakest abstraction possible:
- traverse > mapM
- pure > return
- ``Data.Semigroup.<>`` > ``Data.Monoid.<>`` > ``Data.List.++``
- and so on...
### Style
- HLint is your friend. But not always. If you want to suppress a
hint (e.g. suppressing "Avoid lambda" for consistent and
refactoring-friendly lens definitoions), be sure to include an
explicit type annotation so that it will play nice with
``OverloadedStrings``.
{-# ANN module ("HLint: ignore Avoid lambda" :: String) #-}
## UI Development
For development, we've put a bit of consideration to what type of users we'd
have in mind when making UI decisions. TUI applications don't exactly come to
mind for their usability. They might not be the first choice for casual users,
but that doesn't need to mean they should suffer from good usability. With that
in mind, we develop a few tools to make thinking about UI changes easier.
Note: Please keep in mind that the design framework is by no means complete or
detailed. It's work-in-progress trying to strike a balance between the actual
implementation and a framework useful for communication.
### Personas
Personas are fictional characters created to represent different user types that
might interact with the tool. They're primarily a communication device for
designing the UI when considering their goals, desires and pain points.
#### Nicole Ball
> Most of my time during the day I spent on root cause analysis or thinking
> about solving particular problems.
##### Background
* Software Engineer
* likes to learn new languages which are applicable to real life projects
* loves her `$EDITOR`
#### Primary Goals
* uses e-mail as one primary communication device
* driven to reduce waste in the overall development process
#### Pain Points
* getting interrupted during periods where she needs to concentrate
* loosing oversight over a discussion on a mailing list
#### A Day in the Life
Nicole starts her day checking her e-mails for anything which might have fallen
over during the night and needs her decision. While this can take up some time
to varying degrees, she loves going for a coffee walk with her colleagues
afterwards to exchange news from other teams.
With a good coffee, it is easier to think about the problem she's currently
working on. It's a system which is leaking file descriptors, but she has not
found the root of the problem yet.
After lunch, she does her code reviews. She does get a lot of code review
e-mail, but there is no way of keeping an overview of all that so she uses a
custom filter in the code review UI.
In the afternoon, she will have to join a meeting to see what her
new colleague in Europe is up to.
### Form factor, posture, input methods
* text user interface constrained by a terminal
* posture [...]
* primary input method: keyboard
## References
* About Face: The Essentials of Interaction Design; Cooper, Alan; ISBN-13: 978-1118766576