[Sugar-devel] Fwd: Proposal on how to speed up patch reviews

[Manuel Quiñones]

I would like to applaud the discussion.

Yes, I think we are blocking too much, in regards to stuff that is out
of bugfixing, and polishing the gtk3 port.  This is indeed not good
for the community.

When I started in this project, my patches received reviews from many
people, not only maintainers.  Many discussions went by.  I don't see
that happening anymore.  We also had periodic design meetings guiding
features.  Discussing design after the development is made isn't good,
imho.

It would be great if someone can stand up and become a maintainer.
Maybe you, Daniel?  You have demonstrated your skills with
sugar-build, and helping on the gtk3 port.

2013/3/26 Simon Schampijer <simon at schampijer.de>:
> On 03/26/2013 11:13 AM, Daniel Narvaez wrote:
>>
>> On 26 March 2013 10:53, Simon Schampijer <simon at schampijer.de> wrote:
>>>
>>> That is bad of course. Could have been several reasons. Maybe the
>>> decoupling
>>> of patches and the bug tracker, maybe just felt of the table... Sometimes
>>> a
>>> ping is valid option. But yes, the easiest area to solve.
>>
>>
>> I did try to ping a couple of times on that specific patch. The thing
>> is that if you see maintainers are busy with a ton of stuff you just
>> don't dare pinging too hard and at some point you give up... (Just
>> trying to give a contributor perspective here).
>
>
> Ok, it is good to hear the different stories from the parties involved. This
> is a thread to analyze the situation and see how we can do better.
> Appreciated.
>
>
>>>>> [feature] When it gets to Features things get more tricky. For a
>>>>> Feature
>>>>> first of all the high level goals are important: what need does the
>>>>> Feature
>>>>> address, is it wanted by the community, is the technical approach taken
>>>>> a
>>>>> good one, basically the maintainer has to decide if it is worth taking
>>>>> on
>>>>> maintainership of this feature or not. In the end it might be him who
>>>>> has
>>>>> to
>>>>> deal with arising bug fixes and who is blamed if the software is not a
>>>>> solid
>>>>> product.
>>>>
>>>>
>>>>
>>>> While I agree with you in general, I think maybe we are exagerating a
>>>> bit the responsibility of the maintainers a bit. I tend to think it's
>>>> the whole community which will get the blame if things goes wrong...
>>>> Maintainers have of course a very important role, but they should not
>>>> feel like they alone into this.
>>>
>>>
>>>
>>>  From my experience the work on a feature and the polish of it gets often
>>> underestimated. The first 90% are done in 10% of the time the last 10%
>>> are
>>> done in 90% of the time. I would like to establish a sense of the work
>>> needed to finish a feature, not to make people afraid of starting to work
>>> on
>>> features but to be realistic.
>>
>>
>> That's my experience too. But are you saying the hardest 10% is in the
>> hands of maintainers? That happens in my experience, but it doesn't
>> have to, or at least not most of the time.
>
>
> Yes, I think that happens sometimes. Part of it is maybe if the submitter
> feels responsible or not for a feature after it has been landed and how much
> he is willing to follow up during the process. Of course for the contributor
> it does not help if the process (a) takes long and (b) if the process has
> not started for a long time after he has sent the patches and he is already
> doing something else.
>
> If roles and responsibilities are clear and we have a timeframe and
> guidelines to enforce things can get better.
>
> Simon
>
>
>
>
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
.. manuq ..