During GSoC applications and even after, there was demand for small bugs to work on that was not met. I would like to start marking tickets as 'easyfix' tags to indicate that such tickets would be a good learning process for someone that is not very familiar with LyX's code.
I'm interested in knowing (1) how others think that the above demand for easy bugs should be addressed and (2) how the 'easyfix' tag should be used. Here, I'm suggesting that (2) be the solution to (1). My thoughts are below. Currently the keyword's description [1] is: easyfix: this bug is easy to fix First, let me argue for why I think the current description/use of the keyword is not very useful. Why is it helpful to know if a bug is easy to fix? Perhaps if developers were looking for the best way to spend time, they could look for bugs with a high ratio of priority to easyfix or milestone to easyfix. That would give the best bang for the buck. But I don't think that's how developers think when searching for bugs to work on . I propose the following description (and perhaps a new keyword name?): easyfix: fixing this bug is achievable for a newcommer to LyX development and would be a good learning experience. Thus, boring or repetitive work would not fall under this category (as opposed to the current description of easyfix). What is the ideal ticket to be marked as an easyfix? (a) The fix should be easy in theory. Easy does not necessarily mean it should not take much time. It means that it's clear what needs to be done. (b) One that is not high priority. These should probably be fixed by current developers. (c) It should be a good learning exercise. It should teach a newcommer how to do something, such as introduce a new (but trivial) LFUN, or maybe implement a validation function. (Anything that will likely be useful in the future.) Two questions I have are: How confident should I be that criterion (a) is satisfied? I would only be 100% sure that a ticket is easy to fix if I actually fix it. I plan to be a little risky in assigning this tag and hope that other developers will remove it if I do so mistakenly or that a newcommer will still learn if they try to tackle a bug that is actually too complicated. Should current developers be discouraged from working on 'easyfix' tickets? In my opinion, no. Otherwise, one has to think very carefully before assigning the tag. If developers wants to work on a ticket for any reason, they should be unconstrained. Any thoughts? Scott
