Possible Code Sprint Next Week?

[David Shein]

Greetings,

My name is Dave Shein, and I'm an Adjunct Faculty at Rochester Institute of Technology. Along with Chris Tyler of Seneca College, we are hosting a week long POSSE boot-camp at the RIT campus from June 20^th -24^th. POSSE, sponsored by Red Hat, is a week long educational hand-on seminar in open source process, collaboration, and education. The central purpose of POSSE is to increase awareness and opportunities for Open Source participation in the university setting. All of POSSE participants are university staff or faculty who will take what they learn in POSSE and use that knowledge in CS and related curricula, to spread the word about open source collaboration, and to provide increased educational opportunities for CS related students. Our first two days are spent acclimating our participants to tools and resources of the open source community, but on the third and fourth day of POSSE we will have our participants do a code-sprint. We are looking for opportunities in existing open source projects which have a quick learning curve and setup time for folks with a CS background but who in most cases will not have a great depth of experience working in open source languages. We are particularly interested in having our participants hack on Fedora based projects. The students will have a Fedora F14 & F15/Linux work environment setup as part of their initial orientation, and we are looking for projects that will not have lengthy setup beyond the participants' initial setup.

We obtained information about your open source project through OpenHatch, and would like to know if your project would have elements that would be amenable to our sprint. There will be approximately fifteen to twenty participants working on the sprint in teams of 3 to 5 people each, of whom most are coders. IN ADDITION we are also looking for a project participation opportunity for 3 to 4 non-coders, possibly in the form of testing, copywriting, or editing work. Ideally we would also like to coordinate with a point-person in your organization during the period of the sprint, a person to whom participants could direct questions, perhaps via IRC in real time.

If this is of interest to you please contact me at your earliest convenience. I hope that we can work together soon.

David Malcom Shein

Rochester Institute of Technology

IRC# ProfSheinRIT on freenode

[Aaron S. Meurer]

I think SymPy fits this need.  It only really requires git and Python to develop in (though depending on what you are doing, you may need other tools as well).  And since it is written in Python, the deveopment turnover time is fast, meaning that you can get a lot done in a sprint.

Our issue tracker is at http://code.google.com/p/sympy/issues/list and we have tagged some issues as "easy to fix" http://code.google.com/p/sympy/issues/list?q=label:EasyToFix.  Of course, we're also open to more ambitious contributions, like implementing new features.  

We also have a ton of documentation that could be written or improved, which requires little to no programming experience.  

Aaron Meurer 

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sympy/-/TQT7Mrjtcn8J.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

[Chris Smith]

Is trying to increase covereage a sprint worthy goal?

[Vladimir Perić]

On Tue, Jun 14, 2011 at 4:26 AM, Chris Smith <smi...@gmail.com> wrote:

Is trying to increase covereage a sprint worthy goal?

--

You received this message because you are subscribed to the Google Groups "sympy" group.

To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sympy?hl=en.

Actually, SymPy has fairly good coverage. The things not covered are usually fairly complex (eg. quantum physics modules) and it's not easy to get into them. I know because I tried (the rest of the missing code is usually things like error handling, or stuff in utilities that aren't that important anyway; all-in-all we are at about 82% and that's quite a good result). I think for a sprint it would be a better idea to dig up some more EasyToFix issues, though I suppose working on coverage is ok if nothing else can be found.

--
Vladimir Perić

[Chris Smith]

It might be a nice thing if issues could be ranked by how "liked" they are. Those that have a lot of discussion or are starred by many people might be indicative of fruitful issues to resolve...or vice versa since the more discussed an issue is, the more controversial it may be.

Alternatively, it might be nice if there were some way to vote for issues that we most want resolved.

[Aaron Meurer]

This already exists. The star is a way for users to vote for issues.
The issue tracker is set to sort issues by milestone, then priority,
then number of stars, so the default order you see at
http://code.google.com/p/sympy/issues/list is roughly the order of
priority. I didn't think of including discussion count as a tie
braker. I'll see if I can add that, so it would be milestone, then
priority, then stars, then number of comments, then issue id.

And by the way, if you have the ability to edit labels, feel free to
up the priority of an issue.

Aaron Meurer

[Aaron S. Meurer]

Sorting by the number of comments does't seem to be implemented, so I created http://code.google.com/p/support/issues/detail?id=5446.

Aaron Meurer