From Fedora Project Wiki

No edit summary
 
(5 intermediate revisions by 3 users not shown)
Line 2: Line 2:


Put your idea in a new section.
Put your idea in a new section.
''Instructions:''
# Put in any idea that helped you as a mentor determine if a student is ready to work on your project.  It could be coding, packaging, writing, or other skills.
# If possible, the ''test'' could be a bit of real-world work
#* ''Do not exploit students -- this should be a small bit of work, not a forced contribution.''


== Fedora packaging/reviewing ==
== Fedora packaging/reviewing ==
Line 9: Line 14:
* Select any Fedora package review and do informal one according to Fedora Packaging guidelines
* Select any Fedora package review and do informal one according to Fedora Packaging guidelines


== Forks ==
Fork the project and start hacking. Talk to the mentor on what would be a easy feature to add. Look the the project TODO. Look for something easy enough to be done within a few days. Send patches to the mentor.
This is the "Coding test" for [[Summer Coding 2010 ideas - FSoC]] and [[Summer Coding 2010 ideas - Dorrie]]. Other projects may also use the same approach.
== Coprs ==
I've had a lot of people approach me who don't know python yet :-)  Everything we code for copr will be in python but it is possible that you can pick up enough python knowledge to work on it.
Note that completing this task is not mandatory but if you do it, it will probably make its way into the project (they're real work that are needed in the project eventually).  Currently we're looking for the qualifying criteria in order:
<ol>
<li>Does it work?  Because Copr is such a recent project, we're still in the prototype phase.  Getting code that does what it says is the most important concern.
<li>Does it note where it should be improved?  Lot's of time in prototyping you write something in an ugly manner and expect to fix it up later.  But then you're pulled away to work on something else and someone else has to decide what to fix.  Having comments that help the next person do that are important.
</ol>
Here's a short task that you can try to work on to see if you have what it takes:
=== Write a func module to check license tags ===
This is nothing fancy.  Install func.  Configure it.  Write a func module that you give a URL (http:// or file://) pointing to an SRPM.  It examines the srpm and determines the license tag.  Then it checks that the license tag is on the list of [[Licensing| Fedora approved licenses]] and return whether the SRPM passes that check or not.


[[Category:Summer Coding]]
[[Category:Summer Coding]]
[[Category:Summer Coding 2010]]
[[Category:Summer Coding 2010]]

Latest revision as of 16:37, 19 May 2010

This page is for putting in ideas and suggestions for how mentors can test to see if a student is qualified to work on a technical project. This was formerly referred to as "a coding test" but may not involve code or a test at all.

Put your idea in a new section.

Instructions:

  1. Put in any idea that helped you as a mentor determine if a student is ready to work on your project. It could be coding, packaging, writing, or other skills.
  2. If possible, the test could be a bit of real-world work
    • Do not exploit students -- this should be a small bit of work, not a forced contribution.

Fedora packaging/reviewing

This "real work" test is suitable for projects that needs Fedora packaging skills like KDE Netbook spin.

  • Select any software you'd like to package and prepare package following Fedora Packaging guidelines
  • Select any Fedora package review and do informal one according to Fedora Packaging guidelines

Forks

Fork the project and start hacking. Talk to the mentor on what would be a easy feature to add. Look the the project TODO. Look for something easy enough to be done within a few days. Send patches to the mentor.

This is the "Coding test" for Summer Coding 2010 ideas - FSoC and Summer Coding 2010 ideas - Dorrie. Other projects may also use the same approach.

Coprs

I've had a lot of people approach me who don't know python yet :-) Everything we code for copr will be in python but it is possible that you can pick up enough python knowledge to work on it.

Note that completing this task is not mandatory but if you do it, it will probably make its way into the project (they're real work that are needed in the project eventually). Currently we're looking for the qualifying criteria in order:

  1. Does it work? Because Copr is such a recent project, we're still in the prototype phase. Getting code that does what it says is the most important concern.
  2. Does it note where it should be improved? Lot's of time in prototyping you write something in an ugly manner and expect to fix it up later. But then you're pulled away to work on something else and someone else has to decide what to fix. Having comments that help the next person do that are important.

Here's a short task that you can try to work on to see if you have what it takes:

Write a func module to check license tags

This is nothing fancy. Install func. Configure it. Write a func module that you give a URL (http:// or file://) pointing to an SRPM. It examines the srpm and determines the license tag. Then it checks that the license tag is on the list of Fedora approved licenses and return whether the SRPM passes that check or not.