On Sat, Jan 10, 2015 at 6:49 PM, Scott Kostyshak <skost...@lyx.org> wrote: > On Sat, Jan 10, 2015 at 7:58 AM, Liviu Andronic <landronim...@gmail.com> > wrote: >> Hi Cyrille! >> Some comments below. >> >> >> On Fri, Oct 31, 2014 at 5:46 AM, Cyrille Artho <c.ar...@aist.go.jp> wrote: >>> Hi all, >>> I was very happy to be able to attend this year's GSoC Reunion, as I could >>> learn about a lot of other open source projects that I otherwise probably >>> would never have heard of. >>> It was also nice to meet Stefano, as I had never met any LyXer in person >>> before! >>> >>> At the reunion, I could learn a bit more about Google Code In while talking >>> to Stephanie, who runs that program. To recap, to join we have to provide >>> 100-150 tasks to high school students in the following categories: >>> >>> 1. Code: Tasks related to writing or refactoring code >>> >>> 2. Documentation/Training: Tasks related to creating/editing documents >>> and helping others learn more >>> >>> 3. Outreach/Research Tasks related to community management, >>> outreach/marketing or studying problems and recommending solutions >>> >>> 4. Quality Assurance: Tasks related to testing and ensuring code is of >>> high quality >>> >>> 5. User Interface: Tasks related to user experience research or user >>> interface design and interaction >>> >>> The major differences to GSoC are: >>> >>> * Each task should be "bite-sized", about 2 - 3 hours per student. >>> >>> * We *cannot* choose students: whoever applies is eligible to work on tasks >>> (hence the need for so many tasks). >>> >>> * Stephanie recommended 5 - 7 available mentors, although there are some >>> orgs where one mentor covers nearly all bases. >>> >>> * It is possible to add more tasks later, but at least 100 are recommended >>> so an org does not run out of tasks too soon. >>> >>> * Now it is too late to gather 100 high-quality tasks within just two weeks; >>> but we can take it slowly and collect those tasks over a year! >>> >>> I also talked a bit to Joel, who works on a project that is of roughly >>> similar size as ours, in terms of mentoring power. He also confirmed that >>> collection tasks over a year makes it very easy to have 100 tasks in total. >>> >>> I think we could probably get some tasks for categories 1 (Code) and 4 (QA) >>> from our bug database. Do you think it would be good to have a new tag "GCI" >>> for that? This would mean that the task is not urgent and should be solvable >>> by someone with little prior experience with LyX. (Some experience can be >>> provided by "beginner tasks", which any student who wants to work on actual >>> tasks has to do first to become familiar with the project). >>> >> We already have a freshly minted 'gsoc' tag: >> http://www.lyx.org/trac/query?status=!closed&keywords=~gsoc >> >> We also have a 'easyfix' tag: >> http://www.lyx.org/trac/query?status=!closed&keywords=~easyfix >> >> Scott, can we add a 'gci' tag, too? I suspect that 'gsoc' would be >> used for full-fledged, hardcore projects while 'gci' mostly for >> enhancements that can also be termed as 'easyfix'. Alternatively, we >> can simply keep 'gsoc' & 'easyfix' tag combination as a code for >> Google Code-in relevant tasks... >> >> Cyrille, Scott, what solution would be bestest in this case? >
> I think gci tag makes sense. > Yeah, I also tend to think that 'gci' tag would be more useful. Could you ahead and add it? Thanks, Liviu >>> Other categories, especially 2 (documentation) and 3 (outreach) would not >>> suit the approach of tagging bugs. For this, we would need a new wiki page. >>> >>> I am not very familiar with that aspect of LyX; but I think that we could >>> also benefit from screen captures and videos being updated, or from how-to >>> solutions for specific tasks (such as how to import a table from a >>> spreadsheet, mark it up nicely with LyX' GUI, and then produce a .tex file >>> that can be included in an existing .tex document). >>> >>> Do you think we could get about 20 small-ish tasks collected by next >>> November that way? >>> >> I suspect that a first step would be for us to start triaging >> Bugtracker tickets, and try to pinpoint which are suitable for GSoC, >> and which are suitable for GCI. >> >> I think there are several advantages to this: >> - ideas can be kept on the Bugtracker and not get lost on the wiki >> - ideas can be discussed meaningfully in a single place, to allow >> refining the scope and feasibility of teh task (avoiding telling >> students: "search the ML") >> - when Google related deadlines approach, we can then simply >> cherry-pick from existing and already discussed ideas, and set up our >> Ideas pages >> - we can do this first step with little involvement of our core devels >> and prospective mentors >> >> >>> If so, please discuss if >>> >>> (1) you agree with a new bug tag to mark small bugs that we'd like to get >>> fixed (or if existing tags suffice); >>> >> As discussed above, we already have 'gsoc' and we simply need to start >> tagging relevant tickets with it. And, of course, either 'gsoc' & >> 'easyfix' suffice to signal Google Code-In task; or we need a 'gci' >> tag... >> >> Note: I have to note though that the 'easyfix' tag has had its share >> of controversy, since some tasks may appear easy to fix at first, but >> only for core devels intimately familiar with the code. For newcomers >> some of teh tasks are much harder to pin down. For this reason alone >> perhaps the 'gci' tag is warranted.... > > True but this depends on how we define 'easyfix'. If we define it > appropriately (e.g. at first look, this bug might require minimal > knowledge of LyX's internals to fix. However, we are never sure until > the bug is actually fixed), there is not as much of a problem. > >>> (2) you think we should put up a few wiki pages to cover all five categories >>> (for entries in the bug tracker, we can just provide a link). >>> >> Yes, absolutely. The better we can organize the GSoC process for our >> mentors and core devels, the better our chances of getting more >> mentors involved and nabbing good students. >> >> >>> I personally think it's a worthwhile task. We could even ask students to >>> help with integrating existing GSoC project code, which has not made it into >>> the main repository yet. If we maybe don't have enough manpower to run GSoC >>> again next year, we can perhaps try to join GCI instead? >>> >> I thought a bit about this and here are my thoughts. >> >> From what I see most of our core devels have their hands full between >> real life and maintaining the nuts and bolts of LyX, and ensuring that >> the project is moving in the right direction and doesn't get obsoleted >> (fixing existing bugs and making sure that new software developments >> don't break LyX). With this in mind, I have a feeling that most of our >> devels simply cannot be bothered with GSoC mentoring tasks (or >> admining, e.g. preparing GCI tasks, etc.), which from our experience >> really are almost full-time jobs that eat up much of your available >> time. So with the risk of stating the obvious, the relative lack of >> enthusiasm that we have on lyx-devel can probably be attributed to our >> devels focusing their attention and efforts on more pressing tasks... >> >> So what can we do about this? >> >> I think setting up and preparing the ideas for future GSoC or GCI >> projects greatly improves our odds of actually raising interest from >> prospective mentors (existing core devels). So efforts to triage our >> tickets, correctly assign tags, and starting a discussion on scope and >> feasibility of tasks are a MUST. If we can set up the stage for >> mentors to simply drop in, take the reins, and not bother with all >> this adminning, then some of our devels might find the time for these >> Google projects. To a degree we are already doing this, but thus far >> we haven't quite used the Bugtracker for this, and that's why we must >> follow up on Cyrille's initiative. >> >> Other than this, we really are stuck with the mentoring conundrum. >> This is our bottleneck as far as Google projects are concerned, and >> unless our devels find the time or motivation for pursuing these types >> of projects, there is precious little that we admins can do wrt GSoC >> or GCI... We admins can, of course, and should prepare the stage, >> though... >> >> Regards, >> Liviu >> >> >>> -- >>> Regards, >>> Cyrille Artho - http://artho.com/ >>> Those who will not reason, are bigots, those who cannot, >>> are fools, and those who dare not, are slaves. >>> -- George Gordon Noel Byron >> >> >> >> -- >> Do you think you know what math is? >> http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02 >> Or what it means to be intelligent? >> http://www.ideasroadshow.com/issues/john-duncan-2013-08-30 >> Think again: >> http://www.ideasroadshow.com/library -- Do you think you know what math is? http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02 Or what it means to be intelligent? http://www.ideasroadshow.com/issues/john-duncan-2013-08-30 Think again: http://www.ideasroadshow.com/library
