Hi, See my short response below (re: GCI tag). Scott Kostyshak wrote:
I also agree that a separate tag makes sense. The scope of GCI tasks and GSoC projects are vastly different, and we also want to keep ideas that are not bugs as such in the tracker.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?
The downside is that we have yet another tag, and that many developers may not recognize GCI (but perhaps know about GSoC). For the latter, tasks that take 2 - 3 hours for a relatively inexperienced young developer are ideal.
People can take care of a few introductory tasks (and even not fix current bugs/issues) to gain experience, so some tasks may assume up to about 10 hours of experience with developing LyX. Ideally most non-introductory tasks would assume something between a few hours and ten hours of experience (and probably take the mentor one hour or less to implement).
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. ScottThanks, LiviuOther 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 mentorsIf 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
-- Regards, Cyrille Artho - http://artho.com/ Nothing is more admirable than the fortitude with which millionaires tolerate the disadvantages of their wealth. -- Nero Wolfe
