According to Arc Riley, who is in charge of GSoC and Code-In for the
Python Software Foundation, said that it will help our chances of
acceptance into the program if we create a bio page for our mentors.
He will also require this to work under the PSF if we do not get
accepted.

So I have started this at
https://github.com/sympy/sympy/wiki/GCI-2011-Mentors.  Please add
yourself if you plan to help.  The information that you provide there
is of course completely up to you. Arc recommended putting some basic
contact information, a picture, and a short bio.  This will make it
feel more friendly to the GCI students.  We also may want to create a
more extensive landing page introducing students to the program and to
SymPy if we get accepted.

Aaron Meurer

On Wed, Oct 26, 2011 at 2:01 AM, Aaron Meurer <asmeu...@gmail.com> wrote:
> On Tue, Oct 25, 2011 at 11:13 AM, Vladimir Perić <vlada.pe...@gmail.com> 
> wrote:
>> On Sun, Oct 23, 2011 at 11:01 PM, Aaron Meurer <asmeu...@gmail.com> wrote:
>>> Great!
>>>
>>> I have created labels in the issue tracker, CodeIn-Code,
>>> CodeIn-Documentation, etc., and also CodeIn-Easy, CodeIn-Medium, and
>>> CodeIn-Hard.  If people can tag issues based on
>>> http://code.google.com/p/google-code-in/wiki/GCIAdminMentorInformation
>>> that would be good tasks, this would be great.  We have to have at
>>> least five tasks in each category to apply, and obviously we will need
>>> many more if we are accepted.  Also, we should create new issues for
>>> various things.  If you want to help but don't have the ability to add
>>> labels to issues in the issue tracker, just let me know and I will
>>> give you the access.
>>
>> I also think the Code-In is a great idea (I wanted to comment sooner,
>> but just couldn't find the time). As I've spent a lot of time lately
>> looking at the various issues, I'll try as much as I can to tag them
>> appropriately (and add new issues, if required). It might be a good
>> idea to consider a more thorough cleaning of the issue list now, like
>> we've discussed before (Aaron). Closing old issues lowers cruft and
>> might inspire people to make some more Code-In tasks (was this called
>> GHOP before?).
>
> Yes, this used to be GHOP, though apparently various technicalities
> have changed since then.
>
>>
>>>
>>> By the way, according to people here at the mentor summit who have
>>> participated before, we should not underestimate what some of these
>>> students can do.  So don't be afraid to mark somewhat difficult tasks
>>> for CodeIn.
>>>
>>> Aaron Meurer
>>>
>>> On Sun, Oct 23, 2011 at 2:35 PM, krastanov.ste...@gmail.com
>>> <krastanov.ste...@gmail.com> wrote:
>>>> I would also like to help. Hopefully I'll find the time.
>>>>
>>>> About the translations - I speak Bulgarian and I can probably find few
>>>> people willing to help with French translations.
>>>>
>>>> Stefan Krastanov
>>>>
>>>> On 23 October 2011 21:33, Aaron Meurer <asmeu...@gmail.com> wrote:
>>>>>
>>>>> Another thing: we need to have at least five translation tasks.  We
>>>>> were thinking to just create tasks for translating tutorials.  We need
>>>>> to have people who are fluent in the language to evaluate the task.
>>>>> Apparently, the task should only be considered as completed if the
>>>>> translation is perfect, i.e., from someone who is also fluent, to
>>>>> avoid people using machine translations.  What languages are people
>>>>> fluent in, who are willing to evaluate translations tasks?  Ondrej
>>>>> speaks Czech and Mateusz speaks Polish.
>>
>> I speak Serbian (Bosnian/Croatian/Montenegrian etc) fluently and I can
>> help with Czech, too.
>>
>> I'd also be willing to help with reviews and generally I plan to be
>> around on IRC (time-permitting). In particular I can be around for
>> US-centric holidays and Christmas (since our Christmas is on the 7th),
>> as that webpage you linked to recommends.
>>
>>
>> I also took a look at the categories of tasks we need to have, and I
>> think we are going to have troubles with some:
>>
>>  * Translation. Disregarding the fact that between all of us, we still
>> cover only a few languages, there's a question of _what_ to translate
>> exactly? I think translating the tutorial is fine, but getting people
>> to translate all our documentation would be a bit too much. I don't
>> think it would be used much, it'd almost definitely be outdated and
>> fact is, SymPy just doesn't depend so much on translations and as such
>> we have no framework around it. We can translate the SymPy Live UI at
>> least, though. I'm sure it's impossible but could we somehow waive
>> that requirement?
>
> This is indeed the problem. That is why we decided to just have tasks
> for translating the tutorial.  The thing is, we have to have five
> tasks for all eight categories.  We had some discussion about this
> with Carol and some other people with Code-In experience at the mentor
> summit at a session about Code-In, and we decided that this was best.
>  If you can think of other good documents to translate, that would be
> great, though I doubt that they will actually end up being kept up to
> date after the program ends.  But anyway, I think we have enough
> languages to make five tasks for now.
>
>>
>>  * Research. Seeing as we're talking about some pretty hardcore math
>> here, I doubt the average high school student will be able to
>> contribute. I'm sure we can scrounge up the 5/10 tasks required, but
>> it'll be a stretch.
>
> Apparently, we should not underestimate these students.  For example,
> sqrtdenest was implemented by a GHOP student.  And quite a few high
> school students know calculus and many know even more than that
> (linear algebra, odes, etc.).  So I think for this category we should
> find the issues that we haven't solved simply because we don't know
> the best way to proceed and make tasks for them.  They can be large
> scale (like the assumptions), or small scale (like maybe some
> technicality in the core).  The worst case scenario is that the
> students won't be able to handle them and so they won't be taken, but
> the best case scenario is that we get some genius who comes up with
> some novel ideas on how to do things.
>
>>
>> There's also the question of how many new tasks do we wish to create?
>> Usually, we don't make tasks as such small "chunks" (eg. all the
>> Documentation tasks about See Also Hector made -- I like them though,
>> nothing against it) so I'm worried we might spam our issue tracker a
>> bit if we over do it (not that it doesn't have so many open issues
>> right now). Just something that crossed my mind...
>
> First off, don't worry about spamming the issue tracker.
>
> Actually, what you can do is create a single issue for multiple tasks,
> like I did for http://code.google.com/p/sympy/issues/detail?id=2766.
> The tasks themselves go into the database in google-melange.com, but
> we can run the actual review through our issue tracker/github pull
> requests (Melange is just there to handle the details of the contest).
>  So issues like those will be split into multiple tasks in melange.
>
> This also means that old issues don't really matter much for this,
> though we did decide to create some dummy tasks like "Fix a
> CodeIn-Easy issue in the issue tracker" so that we can add new issues
> after the first pool is released (this was also a suggestion from the
> mentor summit).
>
> A couple more things:
>
> Vladimir: some of those things that we discussed on IRC earlier about
> gathering statistics about the issues and other various things would
> make good tasks.  I'm not entirely sure what category to put them
> under right now, though.
>
> Second, once we have at least five of each category, we need to
> compile them into a wiki page, so we can put a link to it in our
> application. The application is due November 1.  Ondrej, Mateusz, and
> I already wrote up the responses to the other questions at the summit,
> so we just need that. (p.s., Ondrej, should we put that on the wiki
> like we did for
> https://github.com/sympy/sympy/wiki/GSoC-2010-Organization-Application
> ?)
>
> Aaron Meurer
>
>>
>>>>>
>>>>> Aaron Meurer
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups
>>>>> "sympy" group.
>>>>> To post to this group, send email to sympy@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>>>>> sympy+unsubscr...@googlegroups.com.
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/sympy?hl=en.
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "sympy" group.
>>>> To post to this group, send email to sympy@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> sympy+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/sympy?hl=en.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "sympy" group.
>>> To post to this group, send email to sympy@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> sympy+unsubscr...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/sympy?hl=en.
>>>
>>>
>>
>>
>>
>> --
>> Vladimir Perić
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to