Changes

* Git.jr

* Git.jr

* The idea came from one of the suggested proposals for the GSoF for Sugar Labs, but I want to expand it a bit further. While now a days we are working hard to create curriculum for the young for them to learn how to code at a young age, and while we are quickly integrating programming as an essential part of the education system we are not teaching them how to document and share their code properly. So while we are making huge strides to ensure the future generations know how to code we are neglecting the equally important task pf teaching them how to properly share that code with the world and to do in a way that i well documented. The idea is to create a kid friendly verioning repo mainly for the sugar labs platform, but the end goal would be to make this a global entry to the world of git, and other repo's. So the goal is to make a user friendly introduction to version for kids to version their code while also making a documentation system to go along with it. So that kids can start from a young age to document and version their code and programming projects, essentially creating a layer between the user and git that would simplify the way they can version and document the code. This would be done using the git python API to create the UI, and the back end will be in c so that it can run nice and fast.    

* The idea came from one of the suggested proposals for the GSoF for Sugar Labs, but I want to expand it a bit further. While now a days we are working hard to create curriculum for the young for them to learn how to code at a young age, and while we are quickly integrating programming as an essential part of the education system we are not teaching them how to document and share their code properly. So while we are making huge strides to ensure the future generations know how to code we are neglecting the equally important task pf teaching them how to properly share that code with the world and to do in a way that i well documented. The idea is to create a kid friendly verioning repo mainly for the sugar labs platform, but the end goal would be to make this a global entry to the world of git, and other repo's. So the goal is to make a user friendly introduction to version for kids to version their code while also making a documentation system to go along with it. So that kids can start from a young age to document and version their code and programming projects, essentially creating a layer between the user and git that would simplify the way they can version and document the code. This would be done using the git python API to create the UI, and the back end will be in c so that it can run nice and fast.  

* Timeline:

* I am dedicated and passionate and always ready for a challenge. While i lack on amount of experience i make up in my ability to learn and hunger to do so. My introduction to group programming was in High School where i joined the FIRST robotics team in my high school where i became the lead programmer and oversaw all the development of the robot for 4 year (https://github.com/gabox8888/team-paradox-code). In university i also joined the underwater robotics team in which i am a member of the autonomy division of software (https://github.com/mcgill-robotics/auv). So while i have never worked on an open source project i have for the last five year successfully participated in big group projects in which i have contributed substantial amounts of work. I am a passionate individual and i think this project is really super cool and would love to be part of it, i am motivated and love project based learning and i see this as an opportunity to learn a whole lot.

** 0th Week Now: Prototype

*Expansion:

*** Starting now the idea is to prototype some ideas on what the documentation system can be made to simulate the real world yet still be simple to use. The idea is to have some idea of what the project will look by the start of the project.

**   

** Start of Project May 19: Initial analysis of the way journal works right now.

** 1st Week May 17 - May 23: Decide what can stay and be reused and what needs to be rewritten.

* 0th Week Now: Prototype

*** The idea is to have a sort of re-fresh so there will have to be a decision made in what code needs to be kept and what needs to be re implemented

** Starting now the idea is to prototype some ideas on what the documentation system can be made to simulate the real world yet still be simple to use. The idea is to have some idea of what the project will look by the start of the project.

** 2nd Week May 24 - May 30: The Back end

* Start of Project May 19: Initial analysis of the way journal works right now.

***This is the time to rebuild the back end, this will need to handle all the "git" stuff that are simply not "pretty" and have it ready to be accessed by a UI layer that can sit nicely on top.  

* 1st Week May 17 - May 23: Decide what can stay and be reused and what needs to be rewritten.

** 3rd Week May  31 June 6: Finish Back end

** The idea is to have a sort of re-fresh so there will have to be a decision made in what code needs to be kept and what needs to be re implemented

*** The goal for this would be to finish the "git" back end and the documentation journal that will be implemented to nicely and easily store documentation for users.

* 2nd Week May 24 - May 30: The Back end

** 4th Week June 7 - June 13: Start the Front end

**This is the time to rebuild the back end, this will need to handle all the "git" stuff that are simply not "pretty" and have it ready to be accessed by a UI layer that can sit nicely on top.  

*** This is where the UI comes. Mostly done in Python this front end will be a simple and easy way to verison and document sugar lab projects.  

* 3rd Week May  31 June 6: Finish Back end

** 5th Week June 14 -June 20: Finish Front end

** The goal for this would be to finish the "git" back end and the documentation journal that will be implemented to nicely and easily store documentation for users.

*** Finish up the front end UI, and get it ready for some testing.  

* 4th Week June 7 - June 13: Start the Front end

** 6th Week: June 21- June 27: Code Review

** This is where the UI comes. Mostly done in Python this front end will be a simple and easy way to verison and document sugar lab projects.  

*** Commence final testing and code review to head towards completion of the project. Or at least by the end of this week there should be a finished and working project that can version and document the user's code in a nice and simple manner locally.

* 5th Week June 14 -June 20: Finish Front end

** 7th Week  June 28 - July 4th: Moving online

** Finish up the front end UI, and get it ready for some testing.  

*** Now that the local side of the project is up and running we can start working on connecting it to an online repo. This will entail creating a simple solution to exporting it to existing sites such as gitHub or to create a more "kid" friendly alternative where kids can store their code and work on it from home or another computer.     

* 6th Week: June 21- June 27: Code Review

** 8th Week July 5 - July 11: Finishing online

** Commence final testing and code review to head towards completion of the project. Or at least by the end of this week there should be a finished and working project that can version and document the user's code in a nice and simple manner locally.

*** By the end of this week the goal is to have a working and functional mechanism to connect our newly created repo to an online one be it to a new "SugarLabsHub" or to an existing repo website.  

* 7th Week  June 28 - July 4th: Moving online

** 9th Week July 12 - July 18: Integration

** Now that the local side of the project is up and running we can start working on connecting it to an online repo. This will entail creating a simple solution to exporting it to existing sites such as gitHub or to create a more "kid" friendly alternative where kids can store their code and work on it from home or another computer.     

*** This weeks focus is to integrate and make sure it all works together.  

* 8th Week July 5 - July 11: Finishing online

**10th - 12th Week July 19 - August 8: Testing

** By the end of this week the goal is to have a working and functional mechanism to connect our newly created repo to an online one be it to a new "SugarLabsHub" or to an existing repo website.  

*** Beta testing and bug reporting, hopefully i can get some of the community to participate in the testing and bug reporting.  

* 9th Week July 12 - July 18: Integration

**13th Week August 9 - August 15: Regroup and Debug

** This weeks focus is to integrate and make sure it all works together.  

*** Fix final bugs, make changes and implementations that the community might request, ensure that we have robust code that is well documented and ready for release.

*10th - 12th Week July 19 - August 8: Testing

** Final Week: Putting the cherry on top of the cake

** Beta testing and bug reporting, hopefully i can get some of the community to participate in the testing and bug reporting.  

*** This week is the final week, so everything should be tested, documented, and working to perfection and should be ready to expand if need be to anything that this project needs to become. The idea of this week is to have working code that is also modular enough to grow in the future.

*13th Week August 9 - August 15: Regroup and Debug

** Fix final bugs, make changes and implementations that the community might request, ensure that we have robust code that is well documented and ready for release.

* Final Week: Putting the cherry on top of the cake

** This week is the final week, so everything should be tested, documented, and working to perfection and should be ready to expand if need be to anything that this project needs to become. The idea of this week is to have working code that is also modular enough to grow in the future.

===You and the community===

===You and the community===