Wolfy Framework

Wolfy Framework will be the name of the structure I'm going to create. You can also call it : Wolf, or Wolfy. This is the repository for the creation of a homemade framework which will be used for our personal website : Meetoparty. This is a free project. I'm making this sturcture open-source, so you can use it for all the projects you want, but that would be great if you still continue to improve this structure by opening some issues, or advices... There is some rules you need to follow, to be able to build a good framework. Every day, some new rules will be added to the project. To follow the progress of the work here is the link of the specifications : https://docs.google.com/document/d/1x9drbZPp1E9quruxWpDJiWDIRUxgQj789qKa_4joM7o/edit?usp=sharing

Authors

The main author of this structure is : Quentin LOZACH, and he will be help by his friend on the project : Nicolas DEIXONNE. Other poeple will be able to join the project later to create the same structure in another langage for example : Ruby, Python, Java ...

Rules

This is a list of rules and convention I'm going to follow on this project, and I hope that if people are going to code with me, it will be the same for everyone.

Github

Here are some rules related to Github in general and what we are going to do with the repository. We need a good organization to not start with messy code everywhere. Those rules were defined by me, so it's only in my point of view, and from my experiences things that matters, but maybe with some suggestions I'll modify them later in the future depending of the evolution of the project.

1. Don't commit directly on the master before to be sure that your code is working, except if you are fixing a major bug directly on the master. The master branch will be the main one with the current running application and the last working version.
2. When you commit something, try to put a REAL and understable. Example : Commiting some files => Adding login feature.
3. Title format for a commit : [Short title] - description.
4. When you want to create another branch, be sure that is usefull, and don't forget to include all changing of the master each time.

Documentation

Issues

When you are going to open an issue on Github, please be specific related to the problem you have, if you want to ask a question, or if there is a bug somewhere, and you should be able to judge about the priority of this bug. For example a security bug has an high prority. Here is the list of labels related to issues on the project.

1. [API] : If there is something about the API, open an issue with this label.
2. [Core] : If there is something about the core of the framework, not the application part, open an issue with this label.
3. [Database] : If there is something about the Database in general, a method which is not working linked to the database, open an issue with this label.
4. [Question] : If you have a question related to the code, or the framework in general, open an issue with this label.
5. [Bug] - Priority high : If there is a very important bug which is breaking the framework and the structure, open an issue with this label.
6. [Bug] - Priority medium : If there is a bug which might break the structure, open an issue with this label.
7. [Bug] - Priority low : If there is a bug not very important, but which will need to be fixed, open an issue with this label.
8. [Feature] - Create : If you have an idea for a new feature in the framework, open an issue with this label.
9. [Feature] - Improve : If you have an idea to improve an already existing feature in the framework, open an issue with this label.
10. [Suggestion] : If you have a suggestion for any category, open an issue with this label.

PHP

HTML 5

CSS 3