On Sat, Jan 10, 2015 at 1:02 PM, Liviu Andronic <landronim...@gmail.com> wrote: > 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?
I think this just involves editing http://www.lyx.org/trac/wiki/TicketKeywords Let's wait a bit to see if anyone else has an opinion. Scott > > 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
