Provide user with features for PGP encryption and decryption.

All decisions that are going to be made on this project must be in line with following guidelines:

1. User Interface (UI) must be Intuitive enough
2. User Experience (UX) must be designed for user productivity
3. UI must be responsive to user actions
4. Application must be reliable
5. Application must have all basic features that any PGP application should have
6. Multi-platform compatibility (at least Windows, MacOS, Linux)
7. Iterative roll-out with consistent feature set

Technical guidelines:

1. Avoid over-engineering, K.I.S.S.
2. Follow design principles SOLID and DRY
3. Code formatting: Eclipse's default + 120 line width
4. Code must be written in consistent style. Everyone has own preferences but for the sake of code clarity and consistency we need to follow same approach that is already taken.
5. 1 commit = 1 feature, use git squash and rebase to eliminate merge commit as much as possible, keep history clean. Mention task id in commit comment.
6. Documentation: identifier name is a documentation itself! Choose self-descriptive names and there is no need to write additional documentation. Only if identifierNameHappensToBeLongerThan40Letters then yes, shorten it and write javadoc.
7. Exceptions -- make sure exception stack trace is never lost -- either envelope and propagate or write to log with full stack trace
8. Java 8. This project is claimed to be a Stream madness-free zone. Don't try to implement whole feature using Streams.

• Every feature request is discussed before implementation
• Check against project purpose and guidelines
• Check against rest of application functionality (side effects taken into account)
• Capture How To Demo ("HTD") scenarios
• Architect (determine decomposition)
• Implement code
• Implement unit-tests (if applicable and makes sense)
• Manual Test (at least make sure HTD scenarios pass)
• Integrate into rest of the code base (rebase on latest upstream)

Before each feature can be implemented it has to be supplied with a "How To Demo" (HTD) scenario. Which is a simple set of steps and expectations from the user perspective. I.e.:

• Start app
• Menu -> Certificates
• Expected: list of previously imported certificates displayed in table view
• Expected: there is a button to import existing certificate
• Expected: After I import another certificate it appears in table

• master - contains most recent publicly released version
• pilot - contains version that a limited number of people are trying on their machines. This can be considered as User Acceptance Testing
• develop - this branch contains features that are currently being developed
• release/X.X.X.X - temporary branch based on develop that services the code freeze purpose. Only minor pre-releases bug fixes. no new features implemented here. Once done merged to pilot then when ready to master.
• hotfix/x.x.x.Y - temporary branch based on master or pilot that fixes some minor defect. when done merged to upstream branch.

Every time something get's merged into master or pilot the same set of changes needs to be merged into develop and (if any) other release and hotfix branches.