Draft Incubator Policy

1 view
Skip to first unread message

Danese Cooper

unread,
Jul 30, 2008, 8:27:26 PM7/30/08
to open-web...@googlegroups.com, Danese Cooper
Okay, I started hacking on the ASF's Incubation Policy for Open Web
Foundation. See

http://open-web.pbwiki.com/OWF-Incubation-Policy

You'll note that there are many references to referenced pages (in
brackets) which I am chunking through now and will add as I finish
them. Note also I've put Editor's Notes and places where we need to
supply a URL or something in <pointy brackets>.

Dave and I have had some discussion, but it's time to open the
floodgates as we try to apply Apache process to specifications
(together).

Danese

Gabe Wachob

unread,
Jul 30, 2008, 11:27:30 PM7/30/08
to open-web...@googlegroups.com, Danese Cooper
Danese-

This is a great start to kick off discussion.

It seems like there's a lot of assumptions built into this, some of
which may be due to the fact that its copied from ASF.

1) The whole process of "incubation" to "podling" to "project" feels a
bit overkill to me. Some specs work may last only a small number of
months, and thats a *good* thing. It *seems* like the process here
guarantees that can never happen in the OWF. Perhaps I'm wrong.
2) Why do we need the concept of a "parent" ? At least why do we need
multiple "top level" ongoing projects?
3) It seems to me that this process is going to have to take into
account the IPR process requirements that we may (or may not) come up
with. For example, when are non-asserts required? After it becomes a
podling? A project?
4) Some of the Graduation Criteria don't seem right to me. I've
already stated my discomfort with "the alignment/synergy" criteria. In
addition, some of the infrastructure requirements don't seem
applicable to me. Finally, the infrastructure "tax" concept smells
funny to me and seems to raise the bar on participation too high for me.


Also, the attitude towards encouraging activity in ASF seems
inappropriate here. In general, I'm thinking that specs efforts like
the ones we'd like to see would spin up, do their work, and then spin
down relatively quickly, like on the order of a year (hah, yah, thats
not quick to some, but it is for most spec work). I gather that ASF
projects usually last longer than that because they are doing a lot of
ongoing work -- updates, bugfixes, etc. I would *think*, perhaps
naively, that an OWF group would at least go very dormant between
releases - and thats not a thing to discourage...

-Gabe

Ben Laurie

unread,
Jul 31, 2008, 4:55:03 AM7/31/08
to open-web...@googlegroups.com, Danese Cooper
On Thu, Jul 31, 2008 at 4:27 AM, Gabe Wachob <gwa...@wachob.com> wrote:
>
> Danese-
>
> This is a great start to kick off discussion.

I like the contributor/editor/member scale :-)

> It seems like there's a lot of assumptions built into this, some of
> which may be due to the fact that its copied from ASF.
>
> 1) The whole process of "incubation" to "podling" to "project" feels a
> bit overkill to me. Some specs work may last only a small number of
> months, and thats a *good* thing. It *seems* like the process here
> guarantees that can never happen in the OWF. Perhaps I'm wrong.

Presumably because of IPR requirements, in practice each "project"
(probably the wrong name, but sticking ASF terminology for now) will
create a single spec. So, agree that there's probably too many steps
here. Perhaps it should just be incubation leads to "project" with no
intermediate step - but I think retaining the ability for
mentors/members to kill dysfunctional groups is important. Or maybe
even every "project" should effectively be in incubation until it goes
final.

> 2) Why do we need the concept of a "parent" ? At least why do we need
> multiple "top level" ongoing projects?

The ASF does this to avoid duplication or conflicting goals. I don't
think we want to avoid those, so no real need for parents.

> 3) It seems to me that this process is going to have to take into
> account the IPR process requirements that we may (or may not) come up
> with. For example, when are non-asserts required? After it becomes a
> podling? A project?

Can't answer that until we have a process. Apparently we're waiting
for someone else to finish before we can start that. (Why?)

> 4) Some of the Graduation Criteria don't seem right to me. I've
> already stated my discomfort with "the alignment/synergy" criteria.

See above.

> In
> addition, some of the infrastructure requirements don't seem
> applicable to me. Finally, the infrastructure "tax" concept smells
> funny to me and seems to raise the bar on participation too high for me.

Probably you're misunderstanding - at the ASF infrastructure@ is the
team that deal with account creation, mailing lists, DNS etc. The
suggestion is that projects should share that load.

> Also, the attitude towards encouraging activity in ASF seems
> inappropriate here. In general, I'm thinking that specs efforts like
> the ones we'd like to see would spin up, do their work, and then spin
> down relatively quickly, like on the order of a year (hah, yah, thats
> not quick to some, but it is for most spec work). I gather that ASF
> projects usually last longer than that because they are doing a lot of
> ongoing work -- updates, bugfixes, etc. I would *think*, perhaps
> naively, that an OWF group would at least go very dormant between
> releases - and thats not a thing to discourage...

Yes. I presume even extensions to the protocol (e.g. OpenID
extensions) would occur in their own spec group, so this seems very
likely to be true.

David Recordon

unread,
Jul 31, 2008, 5:01:23 AM7/31/08
to open-web...@googlegroups.com, Danese Cooper
Agreed that projects need to get broken down as they most likely won't
go on for ever. I see a project being in incubation until there is a
final spec with IPR signed off. Then it "graduates" and the community
keeps that spec alive with things like a 1.1 revision. The project
community would then police itself around CLAs upfront for each
contributor to the next point release and non-asserts at the end.

--David

Reply all
Reply to author
Forward
0 new messages