Re: [tryton-dev] Easy path for new contributors

[Jan Grasnick | ag kommunikation]

Am 10.07.2014 14:01, schrieb Cédric Krier:
> On 10 Jul 13:15, Jan Grasnick | ag kommunikation wrote:
>> Am 10.07.2014 13:01, schrieb Cédric Krier:
>>> On 10 Jul 12:20, Jan Grasnick | Grasbauer UG wrote:
>>>> Am 10.07.2014 01:10, schrieb Cédric Krier:
>>>>> On 07 Jun 13:59, Udo Spallek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Fri, 06 Jun 2014 19:27:44 +0200 Sergi Almacellas Abellana
>>>>>> <se...@koolpi.com>:
>>>>>>> I have seen in other open source projects that they mark
>>>>>>> easy issues in order to ease the introduction of
>>>>>>> newcomers to the project development, for example [1]. I
>>>>>>> wonder if this will be a good idea for the tryton
>>>>>>> community. Do you think this will be helpful? In order to
>>>>>>> make this happen, this are the required tasks to do: -
>>>>>>> Add some type of mechanism in roundup to mark easy
>>>>>>> tasks.
>>>>>> We could use Roundup Keywords.
>>>> This all is good, but I want to share my concerns with the
>>>> current process (it's more a question than a proposition):
>>>>
>>>> since I always developing on the last release it's always a
>>>> little bit hard for me to contribute:
>>>>
>>>> I detect a bug or think about a possible improvement. Then I
>>>> edit the involved part of the default modules (if it looks to
>>>> me like a bug) or overwrite a method of the core modules (if I
>>>> think it could be an improvement). After I continue with my
>>>> projects - checking if the changes are solving my problem or it
>>>> is only wrong designed approach in my modules. Now I decide
>>>> that it could be a contribution. Next I have to check out or
>>>> update the trunk. Now i need to merge my changes to trunk,
>>>> create an issue, create a code review, create a patch - this is
>>>> a lot of work which interrupts the work I just focused in.
>>>> Because I don't do it very often I need to read the
>>>> contribution guideline each time (possible alzheimer, but
>>>> anyway)
>>> For me, it is the cost to pay to have the community supports your
>>> code. If you don't want, it is fine but you will pay a small part
>>> on each release.
>>
>> Impossible to work on a patch in stable release? Because sometimes
>> you will find a bug while developing something not knowing if it
>> could be fixed in trunk. So there are two ways - comprare changes
>> in trunk or rewriting your module to work in trunk.
>
> Such must be always done on every supported series. So here you are
> again asking for a volunteer to do your homework.
>
Ok, thanks. So I will take a look to fix some easy issues - maybe I find
a way to simplify the workflow in my particular environment.