project: update TODO, README and add CONTRIBUTING

Let's make the lives of newcomers easier :)
parent c31b949e
# Contributing
When contributing to the development of GNOME Calendar, please first discuss the change you wish to
make via issue, email, or any other method with the maintainers before making a change.
Please note we have a code of conduct, please follow it in all your interactions with the project.
## Pull Request Process
1. Ensure your code compiles. Run `make` before creating the pull request.
2. If you're adding new API, it must be properly documented.
3. You may merge the pull request in once you have the sign-off of the maintainers, or if you
do not have permission to do that, you may request the second reviewer to merge it for you.
## Code of Conduct
GNOME Calendar is a project developed based on GNOME Code of Conduct. You can read it below:
### Summary
GNOME creates software for a better world. We achieve this by behaving well towards
each other.
Therefore this document suggests what we consider ideal behaviour, so you know what
to expect when getting involved in GNOME. This is who we are and what we want to be.
There is no official enforcement of these principles, and this should not be interpreted
like a legal document.
### Advice
* **Be respectful and considerate**: Disagreement is no excuse for poor behaviour or personal
attacks. Remember that a community where people feel uncomfortable is not a productive one.
* **Be patient and generous**: If someone asks for help it is because they need it. Do politely
suggest specific documentation or more appropriate venues where appropriate, but avoid
aggressive or vague responses such as "RTFM".
* **Assume people mean well**: Remember that decisions are often a difficult choice between
competing priorities. If you disagree, please do so politely. If something seems outrageous,
check that you did not misinterpret it. Ask for clarification, but do not assume the worst.
* **Try to be concise**: Avoid repeating what has been said already. Making a conversation larger
makes it difficult to follow, and people often feel personally attacked if they receive multiple
messages telling them the same thing.
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
orientation.
### Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [http://contributor-covenant.org/version/1/4][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/4/
Calendar is a calendar application for GNOME.
Design is an ongoing effort, so is development.
The wiki is [here][1]
[1]: https://wiki.gnome.org/Design/Apps/Calendar
# GNOME Calendar
GNOME Calendar is a simple and beautiful calendar application for GNOME. We give
a lot of attention to details, and as such, design is an essential and ongoing
effort.
The wiki is [here][1]
[1]: https://wiki.gnome.org/Design/Apps/Calendar
TODO
- Rework internal GcalWindow working
- Add disable/enable of views
- Rework GcalViews as grid only (WeekView, MonthView, YearView)
- Rework GcalViews to implement the new API (remove every "New API" comment)
- Make GcalTimeSelector an entry
- Properly fix timezone handling
- Rethink signals from GcalManager
- Order events chronologically in views
- Change ordering of events in all-day views (use a custom ordering)
- Add different triggers for hiding the sources view.
- Check for the real need of adding timezone, and check everywhere
- Connect all dconf options to the program
- Check the real need of a caching GcalManager
Design stuff
- How to handle timezones?
- How should a Single Day view look like?
- Need mockups for:
* Day view
* Agenda view
*
- What to do when there's no host set in the event.
Wish-list
- Make GcalEventWidget a composite widget
* Turn into a GtkGrid subclass
* Remove all the custom drawing madness
- Add resize-by-handlers capabilities to GcalEventWidget
# Tasks
[ ] Rework internal GcalWindow working
[ ] Add disable/enable of views
[ ] Rework GcalViews as grid only (WeekView, MonthView, YearView)
[ ] Rework GcalViews to implement the new API (remove every "New API" comment)
[ ] Make GcalTimeSelector an entry
[ ] Properly fix timezone handling
[ ] Rethink signals from GcalManager
[ ] Order events chronologically in views
[ ] Change ordering of events in all-day views (use a custom ordering)
[ ] Add different triggers for hiding the sources view.
[ ] Check for the real need of adding timezone, and check everywhere
[ ] Connect all dconf options to the program
[ ] Check the real need of a caching GcalManager
# Design tasks
[ ] How to handle timezones?
[ ] How should a Single Day view look like?
[ ] Need mockups for:
[ ] Day view
[ ] Agenda view
[ ] Timezone selector
[ ] What to do when there's no host set in the event.
# Wishlist
[ ] Make GcalEventWidget a composite widget
[ ] Turn into a GtkGrid subclass
[ ] Remove all the custom drawing madness
[ ] Add resize-by-handlers capabilities to GcalEventWidget
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment