On 03/26/2013 11:13 AM, Daniel Narvaez wrote:
On 26 March 2013 10:53, Simon Schampijer <si...@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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
