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 <[email protected]>: >>> 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) I don't know if there is a way to simplify this - but making contributions on last release would make some steps obsolete. I know that having all tools handy for a core developer is state of art - but a implementer of projects not always knows all the stuff he needs for contribution. So we possibly loose a lot of input because potential contributors decide to use a custom method in here modules to avoid the noise a contribution could cause. While I'm writing this, a community role like quality manager would be nice: I make my contribution - community go to discuss the improvement and a person with all the tools handy will check in the result in the right manner to trunk. I know that this is more work for somebody but it could lower barriers for people, which is more involved in professional implementation than in "hard core coding". I don't know, if I'm the only one who has this view - but I think it could be discussed, at least at the Unconference. Jan
