Those interested must have found out already that our application as a
GSoC mentoring application was not accepted.
I think we did a good job preparing an application, especially thanks
to Dan Drake, Peter Jeremy, Jason Grout, Harald Schilly, David
Kirkby and Minh Nguyen (please correct me if I missed anyone who
helped with the ideas list). We should take care not to lose the time
spent on this process. Hopefully we can be more organized next year and
get our application accepted.
Even in the preparation process, the GSoC ideas page generated a lot of
interest. It made the libGAP effort more popular and brought proposals
from new comers to implement completely new functionality which could
be useful to a wide audience. Also keeping in mind Jason's suggestion
to reconcile the different ideas list, I have a few suggestions to
provide a better starting point for people who want help out, but
don't know where to start.
- replace the "GSoC 2010" link on the front page of the web site with
a "Help Wanted" or "Get Involved!" link. The "development" section of
the site (which should also be revised) is not enough for this.
- move the "mature" ideas to trac and use keywords to tag them. This
way in order to provide a list of possible projects, we can just link
to a certain trac query. We need to take care to update the
description of the tickets with some newbie friendly text and provide
a contact person and a list of required skills.
For the GSoC application next year, I'd like to be able to tag some
ticket with "gsoc" and put a link to trac for the ideas list.
- agree on a tag to indicate "easy" tickets. This would still be sorted
by component, since the skills depends heavily on the component. This
would help new people find their way through the hundreds of open
tickets on trac.
I am willing to do to some of the documentation/wiki editing necessary
to set this up.
Comments?
Burcin
They said there will be an irc session where not accepted
organizations can ask why, that might be useful for the futures!
+1 to organizing tickets by the level of complexity. i can try to list
easy tickets directly on the website - the only requirement is that
trac provides an rss feed for them ...
h
On Sat, 20 Mar 2010 23:12:56 +1100
Minh Nguyen <nguye...@gmail.com> wrote:
> On Sat, Mar 20, 2010 at 10:39 PM, Burcin Erocal <bur...@erocal.org>
> wrote:
>
> <SNIP>
>
> > - replace the "GSoC 2010" link on the front page of the web site
> > with a "Help Wanted" or "Get Involved!" link. The "development"
> > section of the site (which should also be revised) is not enough
> > for this.
>
> The phrase "Get Involved!" sounds better. There is already a link
> called "Help" which directs you to the Sage standard documentation.
You're right, with "Help Wanted" it's hard to distinguish if it's the
users who want the help or the developers.
> > Comments?
>
> What I gather from your proposals above is that we need to have some
> kind of lists of "easy" tickets for someone to nibble on (chew lightly
> for a few hours).
The first two items were more about using the sage-wishlist target in
trac more efficiently and exposing the list of tasks stored there. For
example some items from the GSoC10 ideas list like i18n of the notebook
or portable c99 libm can/should be trac tickets. Some others, like
kerberos support or slideshow mode, already have tickets, but these
should be more exposed as good projects.
BTW, can anyone explain the difference between the sage-wishlist and
sage-feature milestones?
> The idea of such an "easy" list is to anticipate
> someone coming along and say, "I'm new to Sage. I would like to help
> out with its development. What can I do to start?" In that case, one
> could point the person to that list of "easy" tickets for the person
> to choose one, work on their chosen ticket in order to become familiar
> with the Sage development process. It is very similar to what
> Sebastien Labbe did with ticket #8362 [1] during Sage Days 20. That
> is, have a list of "easy" tickets handy for the time when someone
> wants to start out with Sage development. But how long would such an
> "easy" ticket be around before one actually fix it?
There are lot's of occasions when I look at a bug filed under the
symbolics component and say that it would be easy to fix, but cannot
justify taking the time to fix it then myself. When I actually find
some time to work on bugs, I usually go for the ones that are not
likely to be fixed by other people.
If someone wanted to learn the symbolics module, a great way to start
would be to fix sime of these easy tickets. I'm not good at writing
documentation, but I can always answer questions that come up. I'm just
looking for a way to expose these "easy tickets" to people who might be
interested.
Here are some easy tickets from symbolics:
#5650 speed up gamma_inc
#6949 add symbolic max and min functions
#7507 can't forget some assumptions
#7660 arithmetic with inequalities confusing
#8214 add better error message when symbolic expressions are
called
If you don't mind looking at the pynac source (there is a note on how
to get started here [1]):
#8297 extra parenthesis when typesetting QQ arguments to
symbolic functions
[1] http://wiki.sagemath.org/pynac/start
IMHO, the "trivial" tag you pointed out in another thread doesn't fit
here, since it's intended to specify the severity of the problem.
Though I guess if we're leaving these tickets waiting for newcomers,
they cannot be too critical.
Thank you.
Burcin
I just heard of openhatch and gnome-love, which were born with the same idea:
https://openhatch.org/blog/how-can-openhatch-help-me-contribute-to-free-software/
http://live.gnome.org/GnomeLove
> In order to have a sustainable contributor base, I think Sage needs to
> have some kind of mentoring program along the lines of the Ubuntu
> mentoring program [1]. People on the Sage mailing lists do answer
> questions and try to help each other out. But we're all humans.
> Sometimes we get the feeling that if we send an email to a list asking
> for help, we are asking a stupid question. It is this psychological
> barrier that can prevent a person from taking that crucial first step
> to becoming a contributor to the Sage project.
>
> In the past, I have received private emails from someone about getting
> started on contributing to Sage. Over a period of about a week or so,
> I played the role of mentor for that person. I think that worked out
> pretty well because that person is now familiar with the Sage
> development process and have contributed to Sage. What is required, I
> think, is some means of expanding this mentoring program to encourage
> existing Sage contributors to become mentors for potential Sage
> contributors. A wiki page at least along the line of [1] would be
> nice, together with a list of people who would be willing to be
> mentors.
>
> Thoughts?
I think this mentoring process is a very good idea. After sage days 20, the
sage-combinat devel community is expanding. And I'm (as well as Nicolas and
some other) currently playing a similar role for our new devels. You can see
that on the lengthy review message I've been posting on some ticket. This can
be a very time consuming activity and can be vastly speed up by meeting
physically. I may be wrong but I have the impression that usual sage-days are
aimed at core developers, whereas the one we had in Luminy was much more
targeted on beginners. Maybe announcing a much more open sage-days session
could help. Nevertheless, having such a page on the wiki could be of great
help.
Cheers,
Florent