From Fedora Project Wiki

< GSOC 2012

Revision as of 09:52, 6 April 2012 by Jrabbit (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Contact Information

  • Email Address: jackjrabbit@gmail.com
  • Telephone: just ask.
  • Blog URL: http://twitter.com/jackolas I have another actual blog that I don't use.
  • Freenode IRC Nick: jrabbit
  • TImezone: EST


Please answer following questions.

Why do you want to work with the Fedora Project?

You [Fedora] have an exciting project with user feedback on package updates. I'm passionate about packaging and slick user experience.

Do you have any past involvement with the Fedora project or with any another open source project as a contributor (if possible please add some references as well)?

Not with Fedora. I've written and contributed packages for Fink and Haikuports, worked with Haiku OS for GSOC 2011. I'm currently a teaching assistant in a CS 1 course with Python and Pygame: Course Website. I maintain 2 pypi packages. I worked with Camlistore in the course of GSOC last year (fixing up the python module).

Public code: https://github.com/jrabbit

Did you participate with the past GSoC programs, if so which years, which organizations?

Yes 2011 with Haiku OS. I also participated in GCI 2010 (as a student) and 2011 (as a mentor for Haiku).

Will you continue contributing/ supporting the Fedora project after the GSoC 2012 program, if yes, which team(s)/area(s), you are interested with?

Likely, I don't use Fedora currently however so I am unfamiliar with where my interests would be best applied. QA and python are probably where I would be interested. Providing a nice bridge to PyPi would a fun project with any package manager.

Why should we choose you over the other applicants?

I'm new to Fedora and its systems and can provide a fresh look. I'm familiar with many packaging issues as a desktop user of Mac OS X (Homebrew, macports and fink all have failings). I have years of linux server fiddling behind me, I learn by breaking, a good skill in quality assurance I learned with Firefox's 3.5 branch. As an ex-poweruser-tester I have a unique viewpoint on how to get them to contribute and learn to file good bugs.

Proposal Description

Please describe your proposal in detail. Include:

* An overview of your proposal

A GUI for users to give feedback on updates, provide useful information and relevant screenshots (New addition, ala Google+'s feedback).

* The need you believe it fulfills

http://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Fedora_Gooey_Karma It should lower the barrier to contributing valuable QA data as a poweruser, and give maintainers feedback on their work. It would also communicate information on what has been fixed in the update, in multiple levels of technical proficiency, raw git diff, summary [generated], and the packager's given description, there is a Debian setting in stable that informs users of updates after an apt-get upgrade, this is something I'd like to look into.

* Any relevant experience you have

I've done package manager work with Haiku and made packages for PyPi, Haiku, Debian (Not accepted due to missing manual) and Fink. I'm very familiar with python.

I also know clojure, but I hope no one uses java.

* How do you intend to implement your proposal

MAGIC Starting by making a GUI that does only what the command-line Easy Karma does and working up to more features and making it pretty and more functional (for users and developers).

* Final deliverable of the proposal at the end of the period

A GUI that allows users to give karma to updates, packaged and submitted.

* A rough timeline for your progress

I'm not exactly sure how this will be segmented, I'm being smarter this year and not trying to write multiple pieces of software.

  • Week 1: Test out GUI toolkits for python, see current versions in fedora, see if they meet needs.
  • Week 2: Basic window functionality (have some widgets be populated based on reasonable dummy data)
  • Week 3: String the code up nice and tight with the CLI version.
  • Week 4: Package metadata from Fedora (APIs?), process as needed
  • Week 5: Package and polish.
  • Week 6-10: code, code ,code (Improving based on feedback, adding features)
  • Week 11-12: Documentation, final polish, put a bow on it.
* Any other details you feel we should consider

I look pretty good in a suit jacket.

Have you communicated with a potential mentor? If so, who?

Briefly with tflink.