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. > 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. -- Cédric Krier - B2CK SPRL Email/Jabber: cedric.kr...@b2ck.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpNEc0wI8xPs.pgp
Description: PGP signature
