Changes

no edit summary
Line 12: Line 12:     
* 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.    
+
* 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.     
* What is the timeline for development of your project? The Summer of Code work period is from May 19 - August 22; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (27 June); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.
+
* Timeline:
 +
** 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.
 +
*** 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
 +
** 2nd Week May 24 - May 30: The Back 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.  
 +
** 3rd Week May  31 June 6: Finish Back 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.
 +
** 4th Week June 7 - June 13: Start the Front end
 +
*** 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.
 +
** 5th Week June 14 -June 20: Finish Front end
 +
*** Finish up the front end UI, and get it ready for some testing.
 +
** 6th Week: June 21- June 27: Code Review
 +
*** 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.
 +
** 7th Week  June 28 - July 4th: Moving online
 +
*** 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.   
 +
** 8th Week July 5 - July 11: Finishing online
 +
*** By the end of this week the goal ois to have a working and functional mechanism to connect our newilt created repo to an online one be it to a new "SugarLabsHub" or to an existing repo website.  
 
* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.
 
* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.