Re: Does our Decision Making information need additional instructions?
On Thu, Sep 19, 2013 at 9:08 PM, Kay Schenk kay.sch...@gmail.com wrote: On Sep 18, 2013 3:10 PM, Alexandro Colorado j...@oooes.org wrote: On 9/18/13, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado j...@oooes.org wrote: On 9/10/13, Rob Weir robw...@apache.org wrote: On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado j...@oooes.org wrote: On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado j...@oooes.org wrote: I have recently been impact, on this lack of decision making tasks not being followed (ignoring 72 hr limit, etc) basically breaking the process. So I have a few comments on this. I think you're referring to using lazy concensus . https://openoffice.apache.org/docs/governance/lazyConsensus.html https://community.apache.org/committers/lazyConsensus.html One of the important aspects of Lazy Consensus is that it should be stated at the outset of a communication that this is what will be in effect for whatever is proposed. In other words, proposing something and stating that you will be using Lazy Consensus to implement whatever it is you might want to do is critical to this particular process. So far, I am finding 2 threads that seem to relate to all this: [1] http://markmail.org/message/hsdepqzlfvh33pdr (proposals for wiki, forum , web site extensions, etc) and yes,I did vote +1 on the one design I saw in the issue and using it, but mine was only ONE vote in a series of other comments. and this one, more recent [2] http://markmail.org/message/wlvv7gsnsmcurwfv in which there is claim that something was proposed. Based on the first thread, all I see are suggestions for designs and discussion, but no specific proposal. So, no proposal, no broken lazy consensus process. One important part is focusing on the meritocracy aspect of FLOSS. Is important not only to have a bug but an 'evidence'. Everyone has the right to a voice and have their opinion on implementations. However I think that the impact of that voice should be accompany with actual evidence, and would go into even having to propose an alternative. Deny things for the sole case of opinion shouldn't be enforced, We have a process here at the ASF. Denying something, and I take this to mean denying implementing something, based on opinion is what discussion and building consensus is all about. Exactly why we should consider a more efficient way of discussing it. (I thought you are proposing changes to the DM process) for the reasons explained. otherwise this will leave us to have many unverifiable opinions at a very low cost (think of spam for bitmessage) slowing the project down. There should also be a 'good enough' flag deadline after a certain period of time to get out of locked-in discussions. This is usually used on power negotiations (HBR article on the topic: http://hbswk.hbs.edu/archive/4354.html). We have Lazy Consensus and other decision making processes.The ideas in the article you have above are not the way we make decisions at Apache OpenOffice. Lazy Consensus comes close, but, again, this must be explicitly stated -- This sounds a bit of a technicality 'you didnt use blue ink to fill out your form' kind of situation. or else other participants don't have any idea if you're just discussing something or actually intend to do something. Not sure I understand you here. Why would anyone discuss anything for just the fun of discussing it? Something we do see: Someone talk about an idea, but it is not something that they are wiling/able to do. They just think it is a good idea. But unless someone volunteers it is just talk. I'm not saying yours was an example like this, but it is good to be explicit. A semi-humorous example of one approach is here: http://markmail.org/message/rn2uentbgqipx2a5 The exact format is not critical, but that is one way a committer can make it crystal clear. I understand conventions, I would like to see more conventions myself, I dont understand however when proposal is not a proposal because it didnt say [PROPOSAL]. We have a similar conversation on using dev@for support etc. In my opinion, to a great extent, it depends on the message content. We don't' always adhere to the [PROPOSAL]/[LAZY PROPOSAL] tag, though that would certainly make things more clear. When I see a
Re: Does our Decision Making information need additional instructions?
On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado j...@oooes.org wrote: On 9/10/13, Rob Weir robw...@apache.org wrote: On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado j...@oooes.org wrote: On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado j...@oooes.org wrote: I have recently been impact, on this lack of decision making tasks not being followed (ignoring 72 hr limit, etc) basically breaking the process. So I have a few comments on this. I think you're referring to using lazy concensus . https://openoffice.apache.org/docs/governance/lazyConsensus.html https://community.apache.org/committers/lazyConsensus.html One of the important aspects of Lazy Consensus is that it should be stated at the outset of a communication that this is what will be in effect for whatever is proposed. In other words, proposing something and stating that you will be using Lazy Consensus to implement whatever it is you might want to do is critical to this particular process. So far, I am finding 2 threads that seem to relate to all this: [1] http://markmail.org/message/hsdepqzlfvh33pdr (proposals for wiki, forum , web site extensions, etc) and yes,I did vote +1 on the one design I saw in the issue and using it, but mine was only ONE vote in a series of other comments. and this one, more recent [2] http://markmail.org/message/wlvv7gsnsmcurwfv in which there is claim that something was proposed. Based on the first thread, all I see are suggestions for designs and discussion, but no specific proposal. So, no proposal, no broken lazy consensus process. One important part is focusing on the meritocracy aspect of FLOSS. Is important not only to have a bug but an 'evidence'. Everyone has the right to a voice and have their opinion on implementations. However I think that the impact of that voice should be accompany with actual evidence, and would go into even having to propose an alternative. Deny things for the sole case of opinion shouldn't be enforced, We have a process here at the ASF. Denying something, and I take this to mean denying implementing something, based on opinion is what discussion and building consensus is all about. Exactly why we should consider a more efficient way of discussing it. (I thought you are proposing changes to the DM process) for the reasons explained. otherwise this will leave us to have many unverifiable opinions at a very low cost (think of spam for bitmessage) slowing the project down. There should also be a 'good enough' flag deadline after a certain period of time to get out of locked-in discussions. This is usually used on power negotiations (HBR article on the topic: http://hbswk.hbs.edu/archive/4354.html). We have Lazy Consensus and other decision making processes.The ideas in the article you have above are not the way we make decisions at Apache OpenOffice. Lazy Consensus comes close, but, again, this must be explicitly stated -- This sounds a bit of a technicality 'you didnt use blue ink to fill out your form' kind of situation. or else other participants don't have any idea if you're just discussing something or actually intend to do something. Not sure I understand you here. Why would anyone discuss anything for just the fun of discussing it? Something we do see: Someone talk about an idea, but it is not something that they are wiling/able to do. They just think it is a good idea. But unless someone volunteers it is just talk. I'm not saying yours was an example like this, but it is good to be explicit. A semi-humorous example of one approach is here: http://markmail.org/message/rn2uentbgqipx2a5 The exact format is not critical, but that is one way a committer can make it crystal clear. I understand conventions, I would like to see more conventions myself, I dont understand however when proposal is not a proposal because it didnt say [PROPOSAL]. We have a similar conversation on using dev@ for support etc. In my opinion, to a great extent, it depends on the message content. We don't' always adhere to the [PROPOSAL]/[LAZY PROPOSAL] tag, though that would certainly make things more clear. When I see a statement posted on this list like: Page X has a false statement on it, and unless anyone objects over the next day or so, I will fix it. regardless of what the subject matter is, I have a pretty good idea that this is a lazy consensus statement, and the sender will likely wait a few days and make the fix. When I see a statement like: It seems like page x has a false statement on it. and nothing else, I don't interpret that as a lazy consensus proposal, but rather an info item only. I think Rob's suggestions in this thread to augment what is
Re: Does our Decision Making information need additional instructions?
On 9/18/13, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado j...@oooes.org wrote: On 9/10/13, Rob Weir robw...@apache.org wrote: On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado j...@oooes.org wrote: On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado j...@oooes.org wrote: I have recently been impact, on this lack of decision making tasks not being followed (ignoring 72 hr limit, etc) basically breaking the process. So I have a few comments on this. I think you're referring to using lazy concensus . https://openoffice.apache.org/docs/governance/lazyConsensus.html https://community.apache.org/committers/lazyConsensus.html One of the important aspects of Lazy Consensus is that it should be stated at the outset of a communication that this is what will be in effect for whatever is proposed. In other words, proposing something and stating that you will be using Lazy Consensus to implement whatever it is you might want to do is critical to this particular process. So far, I am finding 2 threads that seem to relate to all this: [1] http://markmail.org/message/hsdepqzlfvh33pdr (proposals for wiki, forum , web site extensions, etc) and yes,I did vote +1 on the one design I saw in the issue and using it, but mine was only ONE vote in a series of other comments. and this one, more recent [2] http://markmail.org/message/wlvv7gsnsmcurwfv in which there is claim that something was proposed. Based on the first thread, all I see are suggestions for designs and discussion, but no specific proposal. So, no proposal, no broken lazy consensus process. One important part is focusing on the meritocracy aspect of FLOSS. Is important not only to have a bug but an 'evidence'. Everyone has the right to a voice and have their opinion on implementations. However I think that the impact of that voice should be accompany with actual evidence, and would go into even having to propose an alternative. Deny things for the sole case of opinion shouldn't be enforced, We have a process here at the ASF. Denying something, and I take this to mean denying implementing something, based on opinion is what discussion and building consensus is all about. Exactly why we should consider a more efficient way of discussing it. (I thought you are proposing changes to the DM process) for the reasons explained. otherwise this will leave us to have many unverifiable opinions at a very low cost (think of spam for bitmessage) slowing the project down. There should also be a 'good enough' flag deadline after a certain period of time to get out of locked-in discussions. This is usually used on power negotiations (HBR article on the topic: http://hbswk.hbs.edu/archive/4354.html). We have Lazy Consensus and other decision making processes.The ideas in the article you have above are not the way we make decisions at Apache OpenOffice. Lazy Consensus comes close, but, again, this must be explicitly stated -- This sounds a bit of a technicality 'you didnt use blue ink to fill out your form' kind of situation. or else other participants don't have any idea if you're just discussing something or actually intend to do something. Not sure I understand you here. Why would anyone discuss anything for just the fun of discussing it? Something we do see: Someone talk about an idea, but it is not something that they are wiling/able to do. They just think it is a good idea. But unless someone volunteers it is just talk. I'm not saying yours was an example like this, but it is good to be explicit. A semi-humorous example of one approach is here: http://markmail.org/message/rn2uentbgqipx2a5 The exact format is not critical, but that is one way a committer can make it crystal clear. I understand conventions, I would like to see more conventions myself, I dont understand however when proposal is not a proposal because it didnt say [PROPOSAL]. We have a similar conversation on using dev@ for support etc. In my opinion, to a great extent, it depends on the message content. We don't' always adhere to the [PROPOSAL]/[LAZY PROPOSAL] tag, though that would certainly make things more clear. When I see a statement posted on this list like: Page X has a false statement on it, and unless anyone objects over the next day or so, I will fix it. regardless of what the subject matter is, I have a pretty good idea that this is a lazy consensus statement, and the sender will likely wait a few days and make the fix. When I see a statement like: It seems like page x has a false statement on it. and nothing else, I don't interpret that as a lazy consensus
Re: Does our Decision Making information need additional instructions?
On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado j...@oooes.org wrote: I have recently been impact, on this lack of decision making tasks not being followed (ignoring 72 hr limit, etc) basically breaking the process. So I have a few comments on this. I think you're referring to using lazy concensus . https://openoffice.apache.org/docs/governance/lazyConsensus.html https://community.apache.org/committers/lazyConsensus.html One of the important aspects of Lazy Consensus is that it should be stated at the outset of a communication that this is what will be in effect for whatever is proposed. In other words, proposing something and stating that you will be using Lazy Consensus to implement whatever it is you might want to do is critical to this particular process. So far, I am finding 2 threads that seem to relate to all this: [1] http://markmail.org/message/hsdepqzlfvh33pdr (proposals for wiki, forum , web site extensions, etc) and yes,I did vote +1 on the one design I saw in the issue and using it, but mine was only ONE vote in a series of other comments. and this one, more recent [2] http://markmail.org/message/wlvv7gsnsmcurwfv in which there is claim that something was proposed. Based on the first thread, all I see are suggestions for designs and discussion, but no specific proposal. So, no proposal, no broken lazy consensus process. One important part is focusing on the meritocracy aspect of FLOSS. Is important not only to have a bug but an 'evidence'. Everyone has the right to a voice and have their opinion on implementations. However I think that the impact of that voice should be accompany with actual evidence, and would go into even having to propose an alternative. Deny things for the sole case of opinion shouldn't be enforced, We have a process here at the ASF. Denying something, and I take this to mean denying implementing something, based on opinion is what discussion and building consensus is all about. Exactly why we should consider a more efficient way of discussing it. (I thought you are proposing changes to the DM process) for the reasons explained. otherwise this will leave us to have many unverifiable opinions at a very low cost (think of spam for bitmessage) slowing the project down. There should also be a 'good enough' flag deadline after a certain period of time to get out of locked-in discussions. This is usually used on power negotiations (HBR article on the topic: http://hbswk.hbs.edu/archive/4354.html). We have Lazy Consensus and other decision making processes.The ideas in the article you have above are not the way we make decisions at Apache OpenOffice. Lazy Consensus comes close, but, again, this must be explicitly stated -- This sounds a bit of a technicality 'you didnt use blue ink to fill out your form' kind of situation. or else other participants don't have any idea if you're just discussing something or actually intend to do something. Not sure I understand you here. Why would anyone discuss anything for just the fun of discussing it? On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk kay.sch...@gmail.com wrote: On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir robw...@apache.org wrote: On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk kay.sch...@gmail.com wrote: The information we currently have on Decision Making can be found in our Orientation section: http://openoffice.apache.org/orientation/decision-making.html On that page, there are explanations for types of decision making used in this project specifically and within the Apache Software Foundation. In my opinion, this is very good how to guide, but somewhat limited as a when to guide. I drafted the orientation pages based on my understanding. I didn't get many comments at the time, so I'm sure there is room for improvement. Most of the source code changes done currently are preceded by a BZ issue. This is wonderfully simple and anyone on the commits list can follow what and why something has been done. In other cases, for much larger changes, discussions have been initiated. So, we would NOT see an action such as deleting an entire module undertaken without discussion. Decision making for these types of change follow a a well-known and followed process. Aside from code changes, there are changes to other areas of the project -- web sites, wiki, forums -- whose changes are not typically noted in BZ. Sometimes there are proposals and discussions, sometimes not. These are the kinds of changes that may need additional clarification with regard to decision making. In summary, what kinds of change for non-source code need a
Re: Does our Decision Making information need additional instructions?
On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado j...@oooes.org wrote: I have recently been impact, on this lack of decision making tasks not being followed (ignoring 72 hr limit, etc) basically breaking the process. So I have a few comments on this. I think you're referring to using lazy concensus . https://openoffice.apache.org/docs/governance/lazyConsensus.html https://community.apache.org/committers/lazyConsensus.html One of the important aspects of Lazy Consensus is that it should be stated at the outset of a communication that this is what will be in effect for whatever is proposed. In other words, proposing something and stating that you will be using Lazy Consensus to implement whatever it is you might want to do is critical to this particular process. So far, I am finding 2 threads that seem to relate to all this: [1] http://markmail.org/message/hsdepqzlfvh33pdr (proposals for wiki, forum , web site extensions, etc) and yes,I did vote +1 on the one design I saw in the issue and using it, but mine was only ONE vote in a series of other comments. and this one, more recent [2] http://markmail.org/message/wlvv7gsnsmcurwfv in which there is claim that something was proposed. Based on the first thread, all I see are suggestions for designs and discussion, but no specific proposal. So, no proposal, no broken lazy consensus process. One important part is focusing on the meritocracy aspect of FLOSS. Is important not only to have a bug but an 'evidence'. Everyone has the right to a voice and have their opinion on implementations. However I think that the impact of that voice should be accompany with actual evidence, and would go into even having to propose an alternative. Deny things for the sole case of opinion shouldn't be enforced, We have a process here at the ASF. Denying something, and I take this to mean denying implementing something, based on opinion is what discussion and building consensus is all about. otherwise this will leave us to have many unverifiable opinions at a very low cost (think of spam for bitmessage) slowing the project down. There should also be a 'good enough' flag deadline after a certain period of time to get out of locked-in discussions. This is usually used on power negotiations (HBR article on the topic: http://hbswk.hbs.edu/archive/4354.html). We have Lazy Consensus and other decision making processes.The ideas in the article you have above are not the way we make decisions at Apache OpenOffice. Lazy Consensus comes close, but, again, this must be explicitly stated -- or else other participants don't have any idea if you're just discussing something or actually intend to do something. On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk kay.sch...@gmail.com wrote: On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir robw...@apache.org wrote: On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk kay.sch...@gmail.com wrote: The information we currently have on Decision Making can be found in our Orientation section: http://openoffice.apache.org/orientation/decision-making.html On that page, there are explanations for types of decision making used in this project specifically and within the Apache Software Foundation. In my opinion, this is very good how to guide, but somewhat limited as a when to guide. I drafted the orientation pages based on my understanding. I didn't get many comments at the time, so I'm sure there is room for improvement. Most of the source code changes done currently are preceded by a BZ issue. This is wonderfully simple and anyone on the commits list can follow what and why something has been done. In other cases, for much larger changes, discussions have been initiated. So, we would NOT see an action such as deleting an entire module undertaken without discussion. Decision making for these types of change follow a a well-known and followed process. Aside from code changes, there are changes to other areas of the project -- web sites, wiki, forums -- whose changes are not typically noted in BZ. Sometimes there are proposals and discussions, sometimes not. These are the kinds of changes that may need additional clarification with regard to decision making. In summary, what kinds of change for non-source code need a [PROPOSAL]/discussion before change? For source changes and non-source changes the idea is essentially the same. It is a judgement call more than a hard rule. That's why we should try to vote in committers who have demonstrated good judgement as well as technical skills. We operate in Commit-Then-Review mode most of the time, except when close to a Release Candidate. We try to avoid unnecessary discussion. A timid committer who needs to review every minor change with is an annoyance to most of the 453 subscribers of the dev
Re: Does our Decision Making information need additional instructions?
On 9/10/13, Rob Weir robw...@apache.org wrote: On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado j...@oooes.org wrote: On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado j...@oooes.org wrote: I have recently been impact, on this lack of decision making tasks not being followed (ignoring 72 hr limit, etc) basically breaking the process. So I have a few comments on this. I think you're referring to using lazy concensus . https://openoffice.apache.org/docs/governance/lazyConsensus.html https://community.apache.org/committers/lazyConsensus.html One of the important aspects of Lazy Consensus is that it should be stated at the outset of a communication that this is what will be in effect for whatever is proposed. In other words, proposing something and stating that you will be using Lazy Consensus to implement whatever it is you might want to do is critical to this particular process. So far, I am finding 2 threads that seem to relate to all this: [1] http://markmail.org/message/hsdepqzlfvh33pdr (proposals for wiki, forum , web site extensions, etc) and yes,I did vote +1 on the one design I saw in the issue and using it, but mine was only ONE vote in a series of other comments. and this one, more recent [2] http://markmail.org/message/wlvv7gsnsmcurwfv in which there is claim that something was proposed. Based on the first thread, all I see are suggestions for designs and discussion, but no specific proposal. So, no proposal, no broken lazy consensus process. One important part is focusing on the meritocracy aspect of FLOSS. Is important not only to have a bug but an 'evidence'. Everyone has the right to a voice and have their opinion on implementations. However I think that the impact of that voice should be accompany with actual evidence, and would go into even having to propose an alternative. Deny things for the sole case of opinion shouldn't be enforced, We have a process here at the ASF. Denying something, and I take this to mean denying implementing something, based on opinion is what discussion and building consensus is all about. Exactly why we should consider a more efficient way of discussing it. (I thought you are proposing changes to the DM process) for the reasons explained. otherwise this will leave us to have many unverifiable opinions at a very low cost (think of spam for bitmessage) slowing the project down. There should also be a 'good enough' flag deadline after a certain period of time to get out of locked-in discussions. This is usually used on power negotiations (HBR article on the topic: http://hbswk.hbs.edu/archive/4354.html). We have Lazy Consensus and other decision making processes.The ideas in the article you have above are not the way we make decisions at Apache OpenOffice. Lazy Consensus comes close, but, again, this must be explicitly stated -- This sounds a bit of a technicality 'you didnt use blue ink to fill out your form' kind of situation. or else other participants don't have any idea if you're just discussing something or actually intend to do something. Not sure I understand you here. Why would anyone discuss anything for just the fun of discussing it? Something we do see: Someone talk about an idea, but it is not something that they are wiling/able to do. They just think it is a good idea. But unless someone volunteers it is just talk. I'm not saying yours was an example like this, but it is good to be explicit. A semi-humorous example of one approach is here: http://markmail.org/message/rn2uentbgqipx2a5 The exact format is not critical, but that is one way a committer can make it crystal clear. I understand conventions, I would like to see more conventions myself, I dont understand however when proposal is not a proposal because it didnt say [PROPOSAL]. We have a similar conversation on using dev@ for support etc. -Rob On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk kay.sch...@gmail.com wrote: On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir robw...@apache.org wrote: On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk kay.sch...@gmail.com wrote: The information we currently have on Decision Making can be found in our Orientation section: http://openoffice.apache.org/orientation/decision-making.html On that page, there are explanations for types of decision making used in this project specifically and within the Apache Software Foundation. In my opinion, this is very good how to guide, but somewhat limited as a when to guide. I drafted the orientation pages based on my understanding. I didn't get many comments at the time, so I'm sure there is room for improvement. Most of the source code changes done currently are preceded by a
Re: Does our Decision Making information need additional instructions?
On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir robw...@apache.org wrote: On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk kay.sch...@gmail.com wrote: The information we currently have on Decision Making can be found in our Orientation section: http://openoffice.apache.org/orientation/decision-making.html On that page, there are explanations for types of decision making used in this project specifically and within the Apache Software Foundation. In my opinion, this is very good how to guide, but somewhat limited as a when to guide. I drafted the orientation pages based on my understanding. I didn't get many comments at the time, so I'm sure there is room for improvement. Most of the source code changes done currently are preceded by a BZ issue. This is wonderfully simple and anyone on the commits list can follow what and why something has been done. In other cases, for much larger changes, discussions have been initiated. So, we would NOT see an action such as deleting an entire module undertaken without discussion. Decision making for these types of change follow a a well-known and followed process. Aside from code changes, there are changes to other areas of the project -- web sites, wiki, forums -- whose changes are not typically noted in BZ. Sometimes there are proposals and discussions, sometimes not. These are the kinds of changes that may need additional clarification with regard to decision making. In summary, what kinds of change for non-source code need a [PROPOSAL]/discussion before change? For source changes and non-source changes the idea is essentially the same. It is a judgement call more than a hard rule. That's why we should try to vote in committers who have demonstrated good judgement as well as technical skills. We operate in Commit-Then-Review mode most of the time, except when close to a Release Candidate. We try to avoid unnecessary discussion. A timid committer who needs to review every minor change with is an annoyance to most of the 453 subscribers of the dev list. So we want to encourage JFDI where appropriate. But it is still a judgement call. But in general, I think (my personal view) a committer should put out a proposal in situations such as: 1) They are unsure of the technical merits of what they want to do. They want an extra pair of eyes to review the proposal point out weaknesses, alternatives, etc. 2) It is a job for more than one person or requires coordination across several subgroups within the project. By putting out a formal proposal you can find additional volunteers and move forward in a coordinated way. 3) A change to one of our websites that impacts terms and conditions, license, copyright, branding, etc. So not a technical change, but a substantive change to content in these areas. These require PMC review. 4) A technical change that breaks backwards compatibility of the product. 5) Changes that break things. Sometimes this is unavoidable. But it should be proposed and coordinated like #2 above. 6) Changes that cannot easily be reversed. Code changes and most website changes are in SVN and can be reverted. But some changes, like administrative bulk actions in BZ, cannot be easily undone. 7) Public statements in behalf of the project, e.g., some blog posts and announcements, press releases, etc. Those are examples, but the list is by no means complete. And for almost any of these there may be cases where CTR or even JFDI is appropriate. I'd take them more as things to think about when developing good judgement. Regards, -Rob These are great guidelines! We should definitely integrate them into the Decision Making page somehow. Number 7 might need more elaboration. Developing good judgement, like so many things in life, is learned by trial and error. It would be great if we could at least better define what we think good judgement is. - MzK Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities. Truth isn't. -- Following the Equator, Mark Twain - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities. Truth isn't. -- Following the Equator, Mark Twain
Re: Does our Decision Making information need additional instructions?
On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk kay.sch...@gmail.com wrote: The information we currently have on Decision Making can be found in our Orientation section: http://openoffice.apache.org/orientation/decision-making.html On that page, there are explanations for types of decision making used in this project specifically and within the Apache Software Foundation. In my opinion, this is very good how to guide, but somewhat limited as a when to guide. I drafted the orientation pages based on my understanding. I didn't get many comments at the time, so I'm sure there is room for improvement. Most of the source code changes done currently are preceded by a BZ issue. This is wonderfully simple and anyone on the commits list can follow what and why something has been done. In other cases, for much larger changes, discussions have been initiated. So, we would NOT see an action such as deleting an entire module undertaken without discussion. Decision making for these types of change follow a a well-known and followed process. Aside from code changes, there are changes to other areas of the project -- web sites, wiki, forums -- whose changes are not typically noted in BZ. Sometimes there are proposals and discussions, sometimes not. These are the kinds of changes that may need additional clarification with regard to decision making. In summary, what kinds of change for non-source code need a [PROPOSAL]/discussion before change? For source changes and non-source changes the idea is essentially the same. It is a judgement call more than a hard rule. That's why we should try to vote in committers who have demonstrated good judgement as well as technical skills. We operate in Commit-Then-Review mode most of the time, except when close to a Release Candidate. We try to avoid unnecessary discussion. A timid committer who needs to review every minor change with is an annoyance to most of the 453 subscribers of the dev list. So we want to encourage JFDI where appropriate. But it is still a judgement call. But in general, I think (my personal view) a committer should put out a proposal in situations such as: 1) They are unsure of the technical merits of what they want to do. They want an extra pair of eyes to review the proposal point out weaknesses, alternatives, etc. 2) It is a job for more than one person or requires coordination across several subgroups within the project. By putting out a formal proposal you can find additional volunteers and move forward in a coordinated way. 3) A change to one of our websites that impacts terms and conditions, license, copyright, branding, etc. So not a technical change, but a substantive change to content in these areas. These require PMC review. 4) A technical change that breaks backwards compatibility of the product. 5) Changes that break things. Sometimes this is unavoidable. But it should be proposed and coordinated like #2 above. 6) Changes that cannot easily be reversed. Code changes and most website changes are in SVN and can be reverted. But some changes, like administrative bulk actions in BZ, cannot be easily undone. 7) Public statements in behalf of the project, e.g., some blog posts and announcements, press releases, etc. Those are examples, but the list is by no means complete. And for almost any of these there may be cases where CTR or even JFDI is appropriate. I'd take them more as things to think about when developing good judgement. Regards, -Rob - MzK Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities. Truth isn't. -- Following the Equator, Mark Twain - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
