Summer of Code/2015/GIT.JR

From Sugar Labs
Jump to: navigation, search

About You

  • Gabriel Cemaj
  • gabriel@cemaj.com
  • Gabriel Cemaj
  • gabox8888
  • Spanish/English
  • San Diego. Any time during the day is usually good
  • This will be first open-source project! How exciting is that? At least i'm excited. I really want to be a part of the open source community mainly because of the community. The idea of working together with all sort of people from all sorts of places and this super sweet common goal while doing in so in an open shared environment seems to me as the programmings answer to the "Giving back" question, and that really moves me. So while still learning, i do so quickly and have plenty of enthusiasm to go around.

About your project

  • 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.
  • 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.
  • Expansion:
    • A possible route this could expand to would be to integrate with the Develop activity to automatically create version of the code every so often. Of course still allowing the user to generate a new version at the click of a button but to also do so automatically. And to create a system to then go back and generate proper documentation.

Timeline

  • 0th Week Now: Prototype
    • 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.
    • 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 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.
  • 9th Week July 12 - July 18: Integration
    • This weeks focus is to integrate and make sure it all works together.
  • 10th - 12th Week July 19 - August 8: Testing
    • Beta testing and bug reporting, hopefully i can get some of the community to participate in the testing and bug reporting.
  • 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

  • Impact on the community:
    • My Answer (Gabriel Cemaj)
      • Like i have stated above i dont think we are doing a good enough job of introducing kids that code how to code with people and how to share their code and how to document their code. I believe that when this project is completed it will serve as a learning tool that will enable kids to become better programmers with better code that is shareable. I this this is an huge investment in their future and their abilities, too many people come to university level Computer Science having never used a versioning system and having never shared their code. We are no longer in the 70's and 80's where one programmer could do a project on his own, we live in the era of collaboration and we need to include this as part of the curriculum.
    • Walter
      • In addition to expanding the Journal concept to include versioning, forking, and cloning, we want to introduce the learner to some of the cultural aspects of FOSS. What better example than GIT, which is the global medium of collaboration.
    • Gonzalo Odirad
      • The impact on the community of this project will be to better the development tools for activities and to help more "hackers" to work together in the creation of activities. By having a tool that allows seeing the changes that where made with each version can help to analyze the creation process.
  • What will you do if you get stuck on your project and your mentor isn't around?
    • Living in the era where Google can provide an answer within seconds, i think that we all have millions of mentors and people that have similar issues all over the world. There are literally thousands of online forums filled with questions and answers concerning a myriad of issue, meaning that if i get stuck on something the likelihood that someone else is/has also been stuck on something similar is quite high. The resources are out there all we need to do is find them, the mentors i think are here for bigger things because for most things the internet is your best friend, if Google doesn't have the answer then Bing does and if they don't then Yahoo! must and so on and so on.
  • How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?
    • I think communication is a super important thing, especially within the community. Be it to get help to resolve issues or to have people test the code i think its super important to be able to let the community know where you stand. From previous experience i know that programs like PODIO are super useful to communicate within large communities and they seem to work really well with development communities, it would be really useful to implement a podio or podio like system to streamline communication among team members. If podio is not something this community is up to then keeping the wiki up to date , the IRC channel and weekly progress emails will become things of high importance as in this way everyone in the community can know exactly where i stand and how i am progressing.

Miscellaneous

  • We want to make sure that you can set up a development environment before the summer starts. Please do one of the following:
  • Describe a great learning experience you had as a child.
    • By the time i was 8, i had taken apart all the old gadgets in my household, well not all of them where old. I did say taken apart the question of weather i put them back together is a different one. This got so bad that my mom called me intestine hands because i dissembled everything i could get my hands on. This led to a fascination with how things worked especially computers, and after destroying the houses computers one too many times my dad decide it was time to put my "skills" to better use. So he took me to one of his friends house where he started to teach me what programming was. We started with a java graphing applet and moved on to what was then called Kids Programming Language, what i learned in those lessons are the things that pushed me to study computer science, to join the robotics team and to never stop coding. It was in those many times frustrating afternoons that i decided what i wanted to do for the rest of my life and i haven't looked back since.
  • Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?
    • Looking at other educational programming languages especially those dealing with younger kids like sugar labs it is very clear that all of them need a better way to teach documentation and versioning, so it occurred to me that there is room here for collaboration especially with the people over at MIT Media Labs and their scratch project. Maybe this cam grow to a sort of standard, really as a git.jr.