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 <[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) > 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. > >> 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. > I think there is no problem to have someone volunteer to do that job > (but I guess it will be hard to find). > Sometimes I do it when I see someone trying to contribute but did not > succeed to do it. I take the initial patch, rework it, submit review > etc. myself and finaly I push it. Nice, but there should be other persons who will do it. So after a code review or a discussion in mailing list there should be the possibility to call a volunteer for contributing this. I think for devs with a up to date environment this could be very easy and we have more contributions.
