Paul,
Thank you for having a very liberal standing on how to handle this.
Regarding your comment "privileged group":
First, like politicians you can always say this is responsibility
not privilege ;)
Technically, I don't think there is a way around this - write access
will not be turned loose. The privileged group will be made bigger,
maybe covering everyone on the dev list if that what you mean by
"community, practically eliminating "privileged" within that community.
Someone has to still give write access to developers. When/who grant
write access?
More comments inline.
On 11/12/2015 9:48 AM, Paul Jakma wrote:
On Thu, 12 Nov 2015, Daniel Walton wrote:
Can you share what you have in mind? I think at this point most everyone
who is going to propose an idea has already done so.
The model I have in mind is that:
- Everyone is responsible for reviewing patches.
I'm happy to go with submissions defaulting to going in, unless issues
are raised. If issues are raised, the contributor gets to negotiate
with
those raising the issues and has to try satisfy them.
I like this idea, it means patches are quickly integrated which everyone
on this wants probably. what if this is your first patch/contribution?
- Contributors, ultimately, are responsible for providing patches that
apply to master.
If submissions default to going in, then applying to master should be
the case and come naturally
Regards,
Jafar
So what's needed is a secretarial role role to keep track of the
status of patches (helped by tools) and keep the rest of the community
informed on that; and a facilitating role to co-ordinate the feeding
in of the accepted patches as needed (often there may be 0
co-ordination needed, or the facilitator can trivially handle things,
but sometimes it will need explicit co-ordination with contributors) -
as well as ensure some basic requirements are met (e.g. supplying a
commit message in an appropriate format).
A small number of people at any given time handle those roles. As it's
quite tedious, I'd say it should be rotated relatively frequently to a
wider pool of volunteers from the community.
Indeed, I think those roles inherently require no more than a small
number of people, given they are about tracking and communication.
(There are potentially aspects of those roles that are independent and
could be carved off to separate people, if needs be).
Basically, the recent 'rounds' model - what needs to be fixed with it?
There's room for other roles too, on infrastructure, testing, etc.
regards,
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
