Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
Chris,
Individuals who contribute to Podlings are doing so as mentors and members
of theY IPMC. There is nothing in the Director role that says they are
required to do so.
You can add me to that list of people who have mentored projects in the
last year (I've been part of something like 7 graduating podlings this
year). In every case I did so as an IPMC member. Doing so did not increase
my responsibilities to other podlings.
I do not understand why you are listing peoples engagement in individual
podlings as evidence that Directors have not delegated oversight of
podlings to the IPMC. It simply is not true, two directors have told you
this, as have multiple IPMC members.
Nobody, that I can see, is proposing another layer in the IPMC. You are
proposing moving a layer to the board (although you don't accept that will
be an outcome). I've suggested refining the decision making process. In the
meantime Benson *has* refined the decision making process and the IPMC
seems to have agreed to it.
Let's focus on whether ComDev and the IPMC want to share some
responsibilities.
Ross
Sent from a mobile device, please excuse mistakes and brevity
On 1 Apr 2013 05:31, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Hi Ross,
-Original Message-
From: Ross Gardler rgard...@opendirective.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Sunday, March 31, 2013 5:20 PM
To: general@incubator.apache.org general@incubator.apache.org
Subject: Re: Incubator structure (was Re: Vote on personal matters:
majority vote vs consensus)
On 31 March 2013 17:08, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Why is it so hard to see that the board is already watching those 22
nascent projects in the same manner they watch the 137 TLPs?
Because they are not watching with the same manner. They are delegating a
huge range of tasks such as IP oversight and mentoring to the IPMC.
Yep this is the sticking point where we disagree -- b/c I disagree with
that.
2 tasks are not a huge range. Also my table of responsibilities in the
proposal [1]
I believe clearly specifies where any responsibility is shifted and not
one of
them is the Board. So I've enumerated at least the concerns of myself and
many others about
a range of tasks, and addressed them (for well over a year). I've heard
zero feedback
from you about what's wrong with my table, and what I've missed, what
could be improved
and have heard nothing but it's wrong (paraphrased) or it doesn't cover
all the tasks
that of course will get dropped on the Board? I've done the work to
document
my thoughts. You don't get to then just keep telling me it's wrong without
specifying
what precisely is wrong about it.
Ross says the Board pays less attention to these (by implication) than
say the 137 TLPs at present. Ross is one Director. Good for him.
I, personally, pay as much attention to the PPMCs as I do to TLPs. I'm
active in the IPMC and thus have more visibility. That doesn't mean they
should be expected to by me or by anyone else.
Actually it should be expected -- there is a reason that people like Jim
mentored AOO -- people like Sam joined in, and so did Greg with AOO and
Bloodhound (all 3 are directors). There is a reason that Bertrand has been
very active in the Incubator with Flex and other recent projects. Same as
Rich with Allura -- Roy helps a lot too with clarifications when needed.
I've seen more than a handful of emails from Brett Porter too, so he's
definitely around.
So, sorry Directors too pay just as much attention to PPMCs and to the
Incubator based on their
own individual Incubator and Director hats, and based on their reporting.
I know other directors (Greg IIRC at least) didn't want the Incubator
specific podling reports to go away (and to only have the summary
at the top of the Incubator report).
I don't think any of the Directors want them to go away. But board reports
are not what the IPMC is about. That is the reporting process within the
foundation and provides the level of oversight into the PPMCs that the
board requires. But the IPMC does *much* more than submit a monthly board
report with a verbatim copy of the podlings individual reports.
What i can see, and what I think even Upayavira and Ross
agree
with -- and you too Benson -- is that there is a grave problem here and
it
needs' a fixin'. My deconstruction proposal does that.
No, I do not agree there is a grave problem. I have denied that
repeatedly.
The IPMC has problems, but in the main it works extremely well.
Fine you don't think it's grave. I don't care how it's classified
('grave',
'purple', 'pink', 'yellow', whatever). There is a problem is what I
probably
should have said.
Look, I hear you that, it's probably possible that folks can come up with
even yet another layer beyond the Shepherds, etc., and that that can goad
Process, policy and best practice
ComDev PMC, I proposed, during budget discussions, that the ComDev PMC should consider budgeting to accelerate the documentation goals of this PMC. Since then the IPMC has been discussing the idea of handing off the documentation parts of their responsibilities to ComDev. This is just a discussion item and is in no way a decision at this point. The idea, as I understand it, is not to pass over any of the podling oversight responsibilities, only the documentation of ASF policies, processes and best practice. I stress, this is just an IPMC discussion, there is certainly no decision at this point, at this point, but it is one that ComDev should be aware of. Sent from a mobile device, please excuse mistakes and brevity
Re: [VOTE] recommend Apache DeltaSpike for graduating out of the incubator
+1 (binding)
On Sat, Mar 30, 2013 at 9:14 PM, Sergio Fernández
sergio.fernan...@salzburgresearch.at wrote:
+1 (non-binding)
On 30/03/13 17:54, Mark Struberg wrote:
Hi!
The Apache DeltaSpike podling is a project which contains common CDI
Extensions which are portable among many different Java EE containers and
even run on standalone CDI containers.
We are now incubating since December 2011 and believe we are ready for
graduation. We've shipped 3 releases and already see wide adoption in the
industry.
We've already done an internal VOTE on the proposal which passed with a
big majority [1].
The voices who raised concerns were mainly afraid of DeltaSpike not being
'finished' yet. But graduation doesn't mean that the product is final and
switches to maintenance, but that it is vital and there is an active
community around it. And this is certainly the case as shown by the 21
votes we got the last days.
Our status file [2] got updated recently and I consider the podling
namesearch task as completed [3].
Thus I'd like to ask the IPMC to VOTE on recommending the attached
graduation proposal to the board.
[+1] yes, go forward
[+0] meh, don't care
[-1] nope, because there's a blocker ${blocker_reason}
The VOTE is open for 72h
txs and LieGrue,
strub
[1]
http://markmail.org/message/**bmhr5woxidmghecohttp://markmail.org/message/bmhr5woxidmgheco
[2]
http://incubator.apache.org/**projects/deltaspike.htmlhttp://incubator.apache.org/projects/deltaspike.html
[3]
https://issues.apache.org/**jira/browse/PODLINGNAMESEARCH-**31https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31
--**--
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to creating a set
of portable CDI (JSR-299) Extensions
for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracekgpetracek at apache.org
Mark Strubergstruberg at apache.org
Pete Muirpmuir at redhat.com
Jason Porterlightguard.jp at gmail.com
Shane Bryzaksbryzak at gmail.com
Rudy de Busscherrdebusscher at apache.org
Christian Kaltepothchristian at kaltepoth.de
Arne Limburgarne.limburg at openknowledge.de
Charles Moulliardcmoulliard at gmail.com
Cody Lerumcody.lerum at gmail.com
Romain Mannu-Buccaurmannibucau at gmail.com
Matthew Jason Bensonmbenson at apache.org
Jim Jagielskijim at apache.org
David Blevinsdblevins at apache.org
Ken Finniganken at kenfinnigan.me
John D. Amentjohndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator DeltaSpike podling encumbered upon the Apache Incubator
Project are hereafter discharged.
https://cwiki.apache.org/**confluence/display/DeltaSpike/**
Graduation+Proposalhttps://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal
--**--**-
To unsubscribe, e-mail:
general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org
For additional
Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
On Mon, Apr 1, 2013 at 5:30 AM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Hi Ross,
-Original Message-
From: Ross Gardler rgard...@opendirective.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Sunday, March 31, 2013 5:20 PM
To: general@incubator.apache.org general@incubator.apache.org
Subject: Re: Incubator structure (was Re: Vote on personal matters:
majority vote vs consensus)
On 31 March 2013 17:08, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Why is it so hard to see that the board is already watching those 22
nascent projects in the same manner they watch the 137 TLPs?
Because they are not watching with the same manner. They are delegating a
huge range of tasks such as IP oversight and mentoring to the IPMC.
Yep this is the sticking point where we disagree -- b/c I disagree with
that.
2 tasks are not a huge range. Also my table of responsibilities in the
proposal [1]
I believe clearly specifies where any responsibility is shifted and not
one of
them is the Board.
There are two responsibilities you list that shift to the board - 1) spots
problems with mentoring 2) fixes problems with mentoring.
Also in your proposal oversight of releases is discarded and therefore I
would add spots problems with releases is also therefore ultimately the
boards responsibility.
Jukka now Benson have IMO been successful in focusing podlings on what
they need to do to graduate and pushing them through the process - rather
than staying for years in the incubator. So I would add this to the list of
what the board would need to pick up.
Lastly I would also say that shifting voting on new projects from a public
to private list is not an improvement and would exclude those proposing
from answering any objections or concerns.
Niall
So I've enumerated at least the concerns of myself and
many others about
a range of tasks, and addressed them (for well over a year). I've heard
zero feedback
from you about what's wrong with my table, and what I've missed, what
could be improved
and have heard nothing but it's wrong (paraphrased) or it doesn't cover
all the tasks
that of course will get dropped on the Board? I've done the work to
document
my thoughts. You don't get to then just keep telling me it's wrong without
specifying
what precisely is wrong about it.
Ross says the Board pays less attention to these (by implication) than
say the 137 TLPs at present. Ross is one Director. Good for him.
I, personally, pay as much attention to the PPMCs as I do to TLPs. I'm
active in the IPMC and thus have more visibility. That doesn't mean they
should be expected to by me or by anyone else.
Actually it should be expected -- there is a reason that people like Jim
mentored AOO -- people like Sam joined in, and so did Greg with AOO and
Bloodhound (all 3 are directors). There is a reason that Bertrand has been
very active in the Incubator with Flex and other recent projects. Same as
Rich with Allura -- Roy helps a lot too with clarifications when needed.
I've seen more than a handful of emails from Brett Porter too, so he's
definitely around.
So, sorry Directors too pay just as much attention to PPMCs and to the
Incubator based on their
own individual Incubator and Director hats, and based on their reporting.
I know other directors (Greg IIRC at least) didn't want the Incubator
specific podling reports to go away (and to only have the summary
at the top of the Incubator report).
I don't think any of the Directors want them to go away. But board reports
are not what the IPMC is about. That is the reporting process within the
foundation and provides the level of oversight into the PPMCs that the
board requires. But the IPMC does *much* more than submit a monthly board
report with a verbatim copy of the podlings individual reports.
What i can see, and what I think even Upayavira and Ross
agree
with -- and you too Benson -- is that there is a grave problem here and
it
needs' a fixin'. My deconstruction proposal does that.
No, I do not agree there is a grave problem. I have denied that
repeatedly.
The IPMC has problems, but in the main it works extremely well.
Fine you don't think it's grave. I don't care how it's classified
('grave',
'purple', 'pink', 'yellow', whatever). There is a problem is what I
probably
should have said.
Look, I hear you that, it's probably possible that folks can come up with
even yet another layer beyond the Shepherds, etc., and that that can goad
people into thinking stuff is fixed around here. Jukka's work was great,
and
I applaud him for it, but as I said at the time, to me we're just adding
more
and more layers to the onion, instead of stripping it down to its roots and
core.
Also it's possible that if you guys continue to add layers, and suggest
mechanisms
for organizing those that are active around here,
Re: [VOTE] recommend Apache DeltaSpike for graduating out of the incubator
+1
Regards,
Alan
On Mar 30, 2013, at 9:54 AM, Mark Struberg strub...@yahoo.de wrote:
Hi!
The Apache DeltaSpike podling is a project which contains common CDI
Extensions which are portable among many different Java EE containers and
even run on standalone CDI containers.
We are now incubating since December 2011 and believe we are ready for
graduation. We've shipped 3 releases and already see wide adoption in the
industry.
We've already done an internal VOTE on the proposal which passed with a big
majority [1].
The voices who raised concerns were mainly afraid of DeltaSpike not being
'finished' yet. But graduation doesn't mean that the product is final and
switches to maintenance, but that it is vital and there is an active
community around it. And this is certainly the case as shown by the 21 votes
we got the last days.
Our status file [2] got updated recently and I consider the podling
namesearch task as completed [3].
Thus I'd like to ask the IPMC to VOTE on recommending the attached graduation
proposal to the board.
[+1] yes, go forward
[+0] meh, don't care
[-1] nope, because there's a blocker ${blocker_reason}
The VOTE is open for 72h
txs and LieGrue,
strub
[1] http://markmail.org/message/bmhr5woxidmgheco
[2] http://incubator.apache.org/projects/deltaspike.html
[3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to creating a set
of portable CDI (JSR-299) Extensions
for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir pmuir at redhat.com
Jason Porter lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau at gmail.com
Matthew Jason Benson mbenson at apache.org
Jim Jagielski jim at apache.org
David Blevins dblevins at apache.org
Ken Finnigan ken at kenfinnigan.me
John D. Ament johndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator DeltaSpike podling encumbered upon the Apache Incubator
Project are hereafter discharged.
https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] recommend Apache DeltaSpike for graduating out of the incubator
+1 (binding)
Matt
On Sat, Mar 30, 2013 at 11:54 AM, Mark Struberg strub...@yahoo.de wrote:
Hi!
The Apache DeltaSpike podling is a project which contains common CDI
Extensions which are portable among many different Java EE containers and
even run on standalone CDI containers.
We are now incubating since December 2011 and believe we are ready for
graduation. We've shipped 3 releases and already see wide adoption in the
industry.
We've already done an internal VOTE on the proposal which passed with a
big majority [1].
The voices who raised concerns were mainly afraid of DeltaSpike not being
'finished' yet. But graduation doesn't mean that the product is final and
switches to maintenance, but that it is vital and there is an active
community around it. And this is certainly the case as shown by the 21
votes we got the last days.
Our status file [2] got updated recently and I consider the podling
namesearch task as completed [3].
Thus I'd like to ask the IPMC to VOTE on recommending the attached
graduation proposal to the board.
[+1] yes, go forward
[+0] meh, don't care
[-1] nope, because there's a blocker ${blocker_reason}
The VOTE is open for 72h
txs and LieGrue,
strub
[1] http://markmail.org/message/bmhr5woxidmgheco
[2] http://incubator.apache.org/projects/deltaspike.html
[3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to creating a set
of portable CDI (JSR-299) Extensions
for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir pmuir at redhat.com
Jason Porter lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau at gmail.com
Matthew Jason Benson mbenson at apache.org
Jim Jagielski jim at apache.org
David Blevins dblevins at apache.org
Ken Finnigan ken at kenfinnigan.me
John D. Ament johndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator DeltaSpike podling encumbered upon the Apache Incubator
Project are hereafter discharged.
https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process, policy and best practice
On Mon, Apr 1, 2013 at 2:58 AM, Ross Gardler rgard...@opendirective.comwrote: ComDev PMC, I proposed, during budget discussions, that the ComDev PMC should consider budgeting to accelerate the documentation goals of this PMC. Since then the IPMC has been discussing the idea of handing off the documentation parts of their responsibilities to ComDev. This is just a discussion item and is in no way a decision at this point. The idea, as I understand it, is not to pass over any of the podling oversight responsibilities, only the documentation of ASF policies, processes and best practice. I stress, this is just an IPMC discussion, there is certainly no decision at this point, at this point, but it is one that ComDev should be aware of. Sent from a mobile device, please excuse mistakes and brevity Can you clarify if these discussions have a pre-requisite that the ComDev PMC have a budget and can hire someone to do this ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: Process, policy and best practice
Sent from a mobile device, please excuse mistakes and brevity On 1 Apr 2013 18:28, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Apr 1, 2013 at 2:58 AM, Ross Gardler rgard...@opendirective.com wrote: ComDev PMC, I proposed, during budget discussions, that the ComDev PMC should consider budgeting to accelerate the documentation goals of this PMC. Since then the IPMC has been discussing the idea of handing off the documentation parts of their responsibilities to ComDev. This is just a discussion item and is in no way a decision at this point. The idea, as I understand it, is not to pass over any of the podling oversight responsibilities, only the documentation of ASF policies, processes and best practice. I stress, this is just an IPMC discussion, there is certainly no decision at this point, at this point, but it is one that ComDev should be aware of. Sent from a mobile device, please excuse mistakes and brevity Can you clarify if these discussions have a pre-requisite that the ComDev PMC have a budget and can hire someone to do this ? The two items are not directly connected in any way. I've made no comment about whether ComDev would want to take this on and, so far, the discussion is only between myself and a couple of IPMC members (on the general list) Ross -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: Process, policy and best practice
On Mon, Apr 1, 2013 at 10:32 AM, Ross Gardler rgard...@opendirective.comwrote: Sent from a mobile device, please excuse mistakes and brevity On 1 Apr 2013 18:28, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Apr 1, 2013 at 2:58 AM, Ross Gardler rgard...@opendirective.com wrote: ComDev PMC, I proposed, during budget discussions, that the ComDev PMC should consider budgeting to accelerate the documentation goals of this PMC. Since then the IPMC has been discussing the idea of handing off the documentation parts of their responsibilities to ComDev. This is just a discussion item and is in no way a decision at this point. The idea, as I understand it, is not to pass over any of the podling oversight responsibilities, only the documentation of ASF policies, processes and best practice. I stress, this is just an IPMC discussion, there is certainly no decision at this point, at this point, but it is one that ComDev should be aware of. Sent from a mobile device, please excuse mistakes and brevity Can you clarify if these discussions have a pre-requisite that the ComDev PMC have a budget and can hire someone to do this ? The two items are not directly connected in any way. I've made no comment about whether ComDev would want to take this on and, so far, the discussion is only between myself and a couple of IPMC members (on the general list) Ross If the budget is not a pre-requisite, how do envision a small PMC like ComDev, taking responsibility of a big task, that the current owner and a much larger PMC has not been able to handle ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: Process, policy and best practice
ComDev could work to attract volunteers. I am sure there are more than a few people on the Incubator dev@ list at the moment who might consider moving over here to work on process and policy documentation... On 1 April 2013 19:19, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Apr 1, 2013 at 10:32 AM, Ross Gardler rgard...@opendirective.com wrote: Sent from a mobile device, please excuse mistakes and brevity On 1 Apr 2013 18:28, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Apr 1, 2013 at 2:58 AM, Ross Gardler rgard...@opendirective.com wrote: ComDev PMC, I proposed, during budget discussions, that the ComDev PMC should consider budgeting to accelerate the documentation goals of this PMC. Since then the IPMC has been discussing the idea of handing off the documentation parts of their responsibilities to ComDev. This is just a discussion item and is in no way a decision at this point. The idea, as I understand it, is not to pass over any of the podling oversight responsibilities, only the documentation of ASF policies, processes and best practice. I stress, this is just an IPMC discussion, there is certainly no decision at this point, at this point, but it is one that ComDev should be aware of. Sent from a mobile device, please excuse mistakes and brevity Can you clarify if these discussions have a pre-requisite that the ComDev PMC have a budget and can hire someone to do this ? The two items are not directly connected in any way. I've made no comment about whether ComDev would want to take this on and, so far, the discussion is only between myself and a couple of IPMC members (on the general list) Ross If the budget is not a pre-requisite, how do envision a small PMC like ComDev, taking responsibility of a big task, that the current owner and a much larger PMC has not been able to handle ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ -- NS
Re: Process, policy and best practice
Because 150+ people tasked with oversight, documentation of processes and procedures of podlings, TLPs and themselves, discussing different views of the past, present and future might not be able to agree to anything, but a small team tasked with just documenting process might get the job done without too much bike shedding. Martijn On Mon, Apr 1, 2013 at 8:19 PM, Luciano Resende luckbr1...@gmail.comwrote: On Mon, Apr 1, 2013 at 10:32 AM, Ross Gardler rgard...@opendirective.com wrote: Sent from a mobile device, please excuse mistakes and brevity On 1 Apr 2013 18:28, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Apr 1, 2013 at 2:58 AM, Ross Gardler rgard...@opendirective.com wrote: ComDev PMC, I proposed, during budget discussions, that the ComDev PMC should consider budgeting to accelerate the documentation goals of this PMC. Since then the IPMC has been discussing the idea of handing off the documentation parts of their responsibilities to ComDev. This is just a discussion item and is in no way a decision at this point. The idea, as I understand it, is not to pass over any of the podling oversight responsibilities, only the documentation of ASF policies, processes and best practice. I stress, this is just an IPMC discussion, there is certainly no decision at this point, at this point, but it is one that ComDev should be aware of. Sent from a mobile device, please excuse mistakes and brevity Can you clarify if these discussions have a pre-requisite that the ComDev PMC have a budget and can hire someone to do this ? The two items are not directly connected in any way. I've made no comment about whether ComDev would want to take this on and, so far, the discussion is only between myself and a couple of IPMC members (on the general list) Ross If the budget is not a pre-requisite, how do envision a small PMC like ComDev, taking responsibility of a big task, that the current owner and a much larger PMC has not been able to handle ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Process, policy and best practice
On 1 April 2013 22:20, Shane Curcuru a...@shanecurcuru.org wrote: On 4/1/2013 2:19 PM, Luciano Resende wrote: On Mon, Apr 1, 2013 at 10:32 AM, Ross Gardler rgard...@opendirective.com **wrote: On 1 Apr 2013 18:28, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Apr 1, 2013 at 2:58 AM, Ross Gardler rgard...@opendirective.com wrote: ... Since then the IPMC has been discussing the idea of handing off the documentation parts of their responsibilities to ComDev. This is just a discussion item and is in no way a decision at this point. The idea, as I understand it, is not to pass over any of the podling oversight responsibilities, only the documentation of ASF policies, processes and best practice. ... If the budget is not a pre-requisite, how do envision a small PMC like ComDev, taking responsibility of a big task, that the current owner and a much larger PMC has not been able to handle ? Luciano has an excellent point in that there's not much to discuss until ComDev sees some clarity on what is being asked. This came up about a year ago on the IPMC and I pushed back. At the time people were calling for the IPMC to be disbanded. I brought the idea to ComDev but made it clear that I was concerned it was simply moving the problem. The ComDev PMC seemed happy to allow me to push back. I did, however, commit to revisiting this if the IPMC got its house in order. In many ways the IPMC has got its house in order. Podlings are graduating and the oversight role of the IPMC is now well managed. It's for this reason that I bring this up again. I agree (mostly) with Shane's observations below. That doesn't mean it is necessarily a good idea, but it does mean it is one worth looking at. I also agree with Martijn who said: Because 150+ people tasked with oversight, documentation of processes and procedures of podlings, TLPs and themselves, discussing different views of the past, present and future might not be able to agree to anything, but a small team tasked with just documenting process might get the job done without too much bike shedding. The role of ComDev would not be to define policy, only to document and curate it. As Greg said when this first came up over a year ago - most of the actual writing is done. As to Luciano's question of whether this can be achieved without a budget, I agree this is a really important question. A further question is whether the ASF will see sufficient benefit from any such investment. That is a question for the ComDev PMC to discuss with the Board if people see sufficient value in taking on this role. For now I would suggest we ask ourselves if moving such activity to ComDev will provide any measurable benefit to the foundation. If there is benefit then we should figure out how we can realise it. Ross I do however think this could be an excellent idea, precisely in part because ComDev is smaller and more focused. I could imagine ComDev changing it's scope to effectively serve as an information shepherd on all of the apache.org/* content focused on our technical communities. I.e. not only serving as owners of community.a.o, where we have friendly overviews and pointers to other info, but also editorial owners of things like /dev. This doesn't mean setting policy for technical matters or svn instructions - this more would mean (I'm imagining) taking responsibility for making the technical information there more understandable and better organized. The issue with the IPMC and the Incubator is multi-fold: - Operations. Overseeing podlings and voting in new ones, graduating ones, etc. This is *not* anything to do with ComDev. - Policy setting. This is the IPMC (or other relevant ASF officers) setting official minimum required policy for the incubation process. This is *not* anything to do with ComDev. - Explaining to the world what the Incubation policies are and guiding newcomers through how IPMC Operations work. This one bit is something that ComDev *might* be able to help with, if I'm seeing what Ross is getting at. Personally, I find the incubator site maddening in terms of explaining to a normal human what the heck to do. There's a chance that if ComDev wanted to help, people here could make significant improvements merely by better explaining the incubator - without having to make policy or podling decisions. That in particular is something that could make use of a hired technical writer, if separately we thought that spending was warranted. Make sense? - Shane -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: Process, policy and best practice
As I see it, the primary attraction here is that we could end up with *one* coherent body of documentation on policies and procedures, available to project new and old. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process, policy and best practice
On Mon, Apr 1, 2013 at 3:22 PM, Ross Gardler rgard...@opendirective.com wrote: The role of ComDev would not be to define policy, only to document and curate it. As Greg said when this first came up over a year ago - most of the actual writing is done. There is no single source of policy for ComDev to document and curate -- there are many conflicting interpretations of policy which are continually relitigated year after year. Consider what it took to assemble the licensing how-to at http://www.apache.org/dev/licensing-howto.html. There was a fair amount of debate once we had a draft (see LEGAL-155), but that's the tip of the iceberg -- the real work was developing a sophisticated enough understanding of a difficult issue to write up a draft which was inoculated against all major objections and could withstand the review phase. I expect that refining http://incubator.apache.org/guides/releasemanagement.html will be a similarly challenging undertaking. I don't see how what needs to be done can be achieved by anybody other than volunteers with significant expertise and patience. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] recommend Apache DeltaSpike for graduating out of the incubator
+ 1 (binding).
All the best as a TLP,
Suresh
On Mar 30, 2013, at 12:54 PM, Mark Struberg strub...@yahoo.de wrote:
Hi!
The Apache DeltaSpike podling is a project which contains common CDI
Extensions which are portable among many different Java EE containers and
even run on standalone CDI containers.
We are now incubating since December 2011 and believe we are ready for
graduation. We've shipped 3 releases and already see wide adoption in the
industry.
We've already done an internal VOTE on the proposal which passed with a big
majority [1].
The voices who raised concerns were mainly afraid of DeltaSpike not being
'finished' yet. But graduation doesn't mean that the product is final and
switches to maintenance, but that it is vital and there is an active
community around it. And this is certainly the case as shown by the 21 votes
we got the last days.
Our status file [2] got updated recently and I consider the podling
namesearch task as completed [3].
Thus I'd like to ask the IPMC to VOTE on recommending the attached graduation
proposal to the board.
[+1] yes, go forward
[+0] meh, don't care
[-1] nope, because there's a blocker ${blocker_reason}
The VOTE is open for 72h
txs and LieGrue,
strub
[1] http://markmail.org/message/bmhr5woxidmgheco
[2] http://incubator.apache.org/projects/deltaspike.html
[3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike Project
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to creating a set
of portable CDI (JSR-299) Extensions
for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir pmuir at redhat.com
Jason Porter lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau at gmail.com
Matthew Jason Benson mbenson at apache.org
Jim Jagielski jim at apache.org
David Blevins dblevins at apache.org
Ken Finnigan ken at kenfinnigan.me
John D. Ament johndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further
RESOLVED, that the initial Apache DeltaSpike PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
RESOLVED, that all responsibilities pertaining to the Apache
Incubator DeltaSpike podling encumbered upon the Apache Incubator
Project are hereafter discharged.
https://cwiki.apache.org/confluence/display/DeltaSpike/Graduation+Proposal
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Process, policy and best practice
On 4/1/2013 6:28 PM, Benson Margulies wrote: As I see it, the primary attraction here is that we could end up with *one* coherent body of documentation on policies and procedures, available to project new and old. Oh, drat. I was really starting to get excited about this project - having one set of documentation that explains to normal humans how we work would be amazingly cool! Then I realized what the date is, and now I know that this must really be some complex April Fool's hoax. - Shane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
Hi Niall, First off, thanks for reading my proposal! Specific comments below: -Original Message- From: Niall Pemberton niall.pember...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Monday, April 1, 2013 7:00 AM To: general-incubator general@incubator.apache.org Subject: Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus) On Mon, Apr 1, 2013 at 5:30 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Ross, -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Sunday, March 31, 2013 5:20 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus) On 31 March 2013 17:08, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Why is it so hard to see that the board is already watching those 22 nascent projects in the same manner they watch the 137 TLPs? Because they are not watching with the same manner. They are delegating a huge range of tasks such as IP oversight and mentoring to the IPMC. Yep this is the sticking point where we disagree -- b/c I disagree with that. 2 tasks are not a huge range. Also my table of responsibilities in the proposal [1] I believe clearly specifies where any responsibility is shifted and not one of them is the Board. There are two responsibilities you list that shift to the board - 1) spots problems with mentoring 2) fixes problems with mentoring. I agree, spots problems with mentoring could potentially fall on the board, if the incoming new project and its 3 ASF members don't spot the problem beforehand. Just like it falls to the the board related to all projects if there are issues (mentoring, the Apache Way or otherwise). Before I add that to my proposal, I would ask you to consider some of my recent emails related to mentoring issues with podlings, and ask that if you think that the IPMC is currently doing a great of spotting problems with mentoring. If you, if you can please cite examples that would be great. I have counter examples (Mesos, for one) wherein which emails requesting help have gone unanswered, but if you have others in support of that, I'd appreciate hearing them. Also in your proposal oversight of releases is discarded and therefore I would add spots problems with releases is also therefore ultimately the boards responsibility. My philosophy is that there can remain a small set of mentors, e.g., these shepherds if you will that ought to volunteer for projects as they come into the ASF and be part of their initial PMC. The initial Champion role should also be an ASF member, until the incoming project is ready to elect its own chair (should happen in 1 year). These same people are likely going to be the same people who are great at checking releases now (sebb, Marvin, others). There doesn't need to be an IPMC for them to do that. Jukka now Benson have IMO been successful in focusing podlings on what they need to do to graduate and pushing them through the process - rather than staying for years in the incubator. So I would add this to the list of what the board would need to pick up. Well sorry, I don't think it's Jukka and Benson. I've never been a shepherd once, neither has Chris Douglas, neither has a bunch of people that have successfully brought podlings through the Incubator as of late. Jukka and Benson aren't necessarily the only reasons that things shaped up around here though I wholly appreciate their efforts. Lastly I would also say that shifting voting on new projects from a public to private list is not an improvement and would exclude those proposing from answering any objections or concerns. Yes, I am +1 for that. In my proposal, I've gone and updated it to shift that responsibility to voting on general@incubator (which as I mention in my proposal will remain). One note I'd add -- in my proposal, responsibility is not directly shifted onto the board, until it's shown that the incoming project's committee is unable to handle it: (see shifted responsibility: The project's PMC. And if not, the project's VP. And if not that, the board or the membership. Just like the current way it works for existing TLPs. ) HTH. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: Process, policy and best practice
On Mon, Apr 1, 2013 at 5:56 PM, Shane Curcuru a...@shanecurcuru.org wrote: On 4/1/2013 6:28 PM, Benson Margulies wrote: As I see it, the primary attraction here is that we could end up with *one* coherent body of documentation on policies and procedures, available to project new and old. Oh, drat. I was really starting to get excited about this project - having one set of documentation that explains to normal humans how we work would be amazingly cool! Then I realized what the date is, and now I know that this must really be some complex April Fool's hoax. - Shane LOL, Good one Shane :) -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: [Shepherds] Incubator report reminders sent for Apr 2013
Hi, Sorry, I just realized I had replied in private and this is a comment for general@. Regards, Dave On Apr 1, 2013, at 4:59 PM, Dave Fisher wrote: I added a Shepherd signup area at the front of the report wiki page. http://wiki.apache.org/incubator/April2013 I signed up for three podlings. Regards, Dave On Apr 1, 2013, at 8:27 AM, Marvin wrote: The next board meeting is scheduled for Wed, 17 April 2013, 10:30:00:00 PST. I have just sent reminder emails to the below addresses, requesting them to supply board reports 2 weeks before the above date (Wed, Apr 3rd). Please recall that the Incubator report is due Wed, Apr 10th. Celix Developerscelix-...@incubator.apache.org Chukwa Developers chukwa-...@incubator.apache.org CloudStack Developers d...@cloudstack.incubator.apache.org Curator Developers d...@curator.incubator.apache.org DeviceMap Developersdevicemap-...@incubator.apache.org Falcon Developers general@incubator.apache.org Hadoop Development Tools Developers d...@hdt.incubator.apache.org Helix Developersd...@helix.incubator.apache.org JSPWiki Developers jspwiki-...@incubator.apache.org Kafka Developersd...@kafka.incubator.apache.org Knox Developers d...@knox.incubator.apache.org Marmotta Developers d...@marmotta.incubator.apache.org Mesos Developersmesos-...@incubator.apache.org MRQL Developers d...@mrql.incubator.apache.org ODF Toolkit Developers odf-...@incubator.apache.org Open Climate Workbench Developers d...@climate.incubator.apache.org Provisionr Developers d...@provisionr.incubator.apache.org Ripple Developers d...@ripple.incubator.apache.org Tajo Developers d...@tajo.incubator.apache.org Tashi Developerstashi-...@incubator.apache.org Tez Developers d...@tez.incubator.apache.org VXQuery Developers vxquery-...@incubator.apache.org - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
