Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Justin Erenkrantz]

On 7/11/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:

Board meetings are another case entirely, but having never listened in
on one, I don't know how practical they'd be to hold via other means.
I suspect it would be difficult though.


Any one can dial in to the Board meetings.  It's honestly not *that*
exciting.  =)  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Garrett Rooney]

On 7/11/06, Brian McCallister <[EMAIL PROTECTED]> wrote:


On Jul 11, 2006, at 12:46 PM, Cliff Schmidt wrote:

> "IRC can be used by a podling to bring new people up to speed (e.g.
> Q&A between available committers and interested users/contributors),
> although such sessions should be archived and made available to those
> not able to attend.  However, using IRC as a means to conduct
> development/architecture discussions is discouraged.  Even with the
> best intentions, experience has shown that it is difficult to maintain
> such discussions without implicit decisions being made in the
> process."

Just to call a spade a spade...

Perhaps things like members' and board meetings should also avoid IRC
if a blanket statement that making decisions, even implicit ones, in
IRC is bad?


As I understand it, board and members meetings are legally required to
"occur" at some place and time, so it's not really easy to have them
via email.  I'm not sure if it's totally impossible to have them via
email, but it's certainly harder.

In any event, with regard to member's meetings, it's not like a whole
lot is really "decided" during the IRC conversations, everything
that's being said in the reports is basically cut and pasted into the
channel, and it's all pretty transparent for those who aren't there.

Board meetings are another case entirely, but having never listened in
on one, I don't know how practical they'd be to hold via other means.
I suspect it would be difficult though.

-garrett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[David Blevins]

On Jul 11, 2006, at 12:46 PM, Cliff Schmidt wrote:


"IRC can be used by a podling to bring new people up to speed (e.g.
Q&A between available committers and interested users/contributors),
although such sessions should be archived and made available to those
not able to attend.  However, using IRC as a means to conduct
development/architecture discussions is discouraged.  Even with the
best intentions, experience has shown that it is difficult to maintain
such discussions without implicit decisions being made in the
process."


Personally, I'd cut out the part at the beginning which says what IRC  
can be used for and just start right out with "Using IRC as a means  
to"


Once you start listing what is allowed, it by default disallows  
anything not listed.  Unless that was the intent.


-David



Thoughts?

Cliff

On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:

Jean-


> Given this paragraph in the committers guide [1]:
>
> > Everything -- but everything-- inside the Apache world occurs  
or is reflected in email. As some people say, 'If it isn't in my  
email, it didn't happen.'

>
> Would adding this sentence to the end help?
>
>Decisions only get made on Apache mail lists -- not anywhere
>off list, such as IRC, IM, or private emails.


yes! I like it! I'd like to provide a patch, or go ahead if you have
"write" rights.

-Matthias

> > btw. 404 for:
> > http://incubator.apache.org/howtoparticipate.html
>
> oof! some post-docathon moldly links need to be cleaned up.  
thanks for

> pointing it out.
>
>  -jean
>
> [1] http://incubator.apache.org/guides/committer.html
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Brian McCallister]

On Jul 11, 2006, at 12:46 PM, Cliff Schmidt wrote:


"IRC can be used by a podling to bring new people up to speed (e.g.
Q&A between available committers and interested users/contributors),
although such sessions should be archived and made available to those
not able to attend.  However, using IRC as a means to conduct
development/architecture discussions is discouraged.  Even with the
best intentions, experience has shown that it is difficult to maintain
such discussions without implicit decisions being made in the
process."


Just to call a spade a spade...

Perhaps things like members' and board meetings should also avoid IRC  
if a blanket statement that making decisions, even implicit ones, in  
IRC is bad?


-Brian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Jean T. Anderson]

I'll wait to see if there's anymore feedback on Cliff's wording, then
will add this to the committers guide.

 -jean


Cliff Schmidt wrote:
> On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> 
>> > below) and other recent threads, here's what I would propose also be
>> > doc'd:
>> >
>> > "IRC can be used by a podling to bring new people up to speed (e.g.
>> > Q&A between available committers and interested users/contributors),
>> > although such sessions should be archived and made available to those
>> > not able to attend.  However, using IRC as a means to conduct
>> > development/architecture discussions is discouraged.  Even with the
>> > best intentions, experience has shown that it is difficult to maintain
>> > such discussions without implicit decisions being made in the
>> > process."
>>
>> that sounds good. it makes clear that IRC *can* be used for Q/A. and
>> it should be
>> made public. For instance for a Q&A "session" the content could/should
>> end-up in a FAQ or the FAQ should/could be enhanced.
>>
>> also no dev/arch decissions is mentioned.
> 
> 
> Just to be clear, this proposed piece of text was meant to supplement
> what we have now that categorically excludes off-list decision making.
> 
> Cliff
> 
>> > On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
>> > > Jean-
>> > >
>> > >
>> > > > Given this paragraph in the committers guide [1]:
>> > > >
>> > > > > Everything -- but everything-- inside the Apache world occurs
>> or is reflected in email. As some people say, 'If it isn't in my
>> email, it didn't happen.'
>> > > >
>> > > > Would adding this sentence to the end help?
>> > > >
>> > > >Decisions only get made on Apache mail lists -- not anywhere
>> > > >off list, such as IRC, IM, or private emails.
>> > >
>> > >
>> > > yes! I like it! I'd like to provide a patch, or go ahead if you have
>> > > "write" rights.
>> > >
>> > > -Matthias
>> > >
>> > > > > btw. 404 for:
>> > > > > http://incubator.apache.org/howtoparticipate.html
>> > > >
>> > > > oof! some post-docathon moldly links need to be cleaned up.
>> thanks for
>> > > > pointing it out.
>> > > >
>> > > >  -jean
>> > > >
>> > > > [1] http://incubator.apache.org/guides/committer.html
>> > > >
>> > > >
>> -
>> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Matthias Wessendorf
>> > >
>> > > futher stuff:
>> > > blog: http://jroller.com/page/mwessendorf
>> > > mail: mwessendorf-at-gmail-dot-com
>> > >
>> > > -
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>> -- 
>> Matthias Wessendorf
>>
>> futher stuff:
>> blog: http://jroller.com/page/mwessendorf
>> mail: mwessendorf-at-gmail-dot-com
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Matthias Wessendorf]

> also no dev/arch decissions is mentioned.

Just to be clear, this proposed piece of text was meant to supplement
what we have now that categorically excludes off-list decision making.


yes. What I tried to say is: "I like that the *do no dev/arch
decissions* offline is mentioned in your text"

:)


Cliff

> > On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > Jean-
> > >
> > >
> > > > Given this paragraph in the committers guide [1]:
> > > >
> > > > > Everything -- but everything-- inside the Apache world occurs or is 
reflected in email. As some people say, 'If it isn't in my email, it didn't happen.'
> > > >
> > > > Would adding this sentence to the end help?
> > > >
> > > >Decisions only get made on Apache mail lists -- not anywhere
> > > >off list, such as IRC, IM, or private emails.
> > >
> > >
> > > yes! I like it! I'd like to provide a patch, or go ahead if you have
> > > "write" rights.
> > >
> > > -Matthias
> > >
> > > > > btw. 404 for:
> > > > > http://incubator.apache.org/howtoparticipate.html
> > > >
> > > > oof! some post-docathon moldly links need to be cleaned up. thanks for
> > > > pointing it out.
> > > >
> > > >  -jean
> > > >
> > > > [1] http://incubator.apache.org/guides/committer.html
> > > >
> > > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > futher stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Matthias Wessendorf
>
> futher stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Cliff Schmidt]

On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:

> below) and other recent threads, here's what I would propose also be
> doc'd:
>
> "IRC can be used by a podling to bring new people up to speed (e.g.
> Q&A between available committers and interested users/contributors),
> although such sessions should be archived and made available to those
> not able to attend.  However, using IRC as a means to conduct
> development/architecture discussions is discouraged.  Even with the
> best intentions, experience has shown that it is difficult to maintain
> such discussions without implicit decisions being made in the
> process."

that sounds good. it makes clear that IRC *can* be used for Q/A. and
it should be
made public. For instance for a Q&A "session" the content could/should
end-up in a FAQ or the FAQ should/could be enhanced.

also no dev/arch decissions is mentioned.


Just to be clear, this proposed piece of text was meant to supplement
what we have now that categorically excludes off-list decision making.

Cliff


> On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > Jean-
> >
> >
> > > Given this paragraph in the committers guide [1]:
> > >
> > > > Everything -- but everything-- inside the Apache world occurs or is 
reflected in email. As some people say, 'If it isn't in my email, it didn't happen.'
> > >
> > > Would adding this sentence to the end help?
> > >
> > >Decisions only get made on Apache mail lists -- not anywhere
> > >off list, such as IRC, IM, or private emails.
> >
> >
> > yes! I like it! I'd like to provide a patch, or go ahead if you have
> > "write" rights.
> >
> > -Matthias
> >
> > > > btw. 404 for:
> > > > http://incubator.apache.org/howtoparticipate.html
> > >
> > > oof! some post-docathon moldly links need to be cleaned up. thanks for
> > > pointing it out.
> > >
> > >  -jean
> > >
> > > [1] http://incubator.apache.org/guides/committer.html
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > futher stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Matthias Wessendorf]

below) and other recent threads, here's what I would propose also be
doc'd:

"IRC can be used by a podling to bring new people up to speed (e.g.
Q&A between available committers and interested users/contributors),
although such sessions should be archived and made available to those
not able to attend.  However, using IRC as a means to conduct
development/architecture discussions is discouraged.  Even with the
best intentions, experience has shown that it is difficult to maintain
such discussions without implicit decisions being made in the
process."


that sounds good. it makes clear that IRC *can* be used for Q/A. and
it should be
made public. For instance for a Q&A "session" the content could/should
end-up in a FAQ or the FAQ should/could be enhanced.

also no dev/arch decissions is mentioned.

-Matt


Thoughts?

Cliff

On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Jean-
>
>
> > Given this paragraph in the committers guide [1]:
> >
> > > Everything -- but everything-- inside the Apache world occurs or is 
reflected in email. As some people say, 'If it isn't in my email, it didn't happen.'
> >
> > Would adding this sentence to the end help?
> >
> >Decisions only get made on Apache mail lists -- not anywhere
> >off list, such as IRC, IM, or private emails.
>
>
> yes! I like it! I'd like to provide a patch, or go ahead if you have
> "write" rights.
>
> -Matthias
>
> > > btw. 404 for:
> > > http://incubator.apache.org/howtoparticipate.html
> >
> > oof! some post-docathon moldly links need to be cleaned up. thanks for
> > pointing it out.
> >
> >  -jean
> >
> > [1] http://incubator.apache.org/guides/committer.html
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Matthias Wessendorf
>
> futher stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Jean T. Anderson]

Matthias Wessendorf wrote:
> Jean-
> 
> 
>> Given this paragraph in the committers guide [1]:
>>
>> > Everything -- but everything-- inside the Apache world occurs or is
>> reflected in email. As some people say, 'If it isn't in my email, it
>> didn't happen.'
>>
>> Would adding this sentence to the end help?
>>
>>Decisions only get made on Apache mail lists -- not anywhere
>>off list, such as IRC, IM, or private emails.
> 
> yes! I like it! I'd like to provide a patch, or go ahead if you have
> "write" rights.

I'll go ahead and update it -- and fix those broken links at the same time.

 -jean

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[doc] IRC guidelines (was Re: Extensible Ajax Platform (XAP) Project Update)

[Cliff Schmidt]

More explicit documentation is usually a good thing, and having clear
docs stating that decisions must only take place on the mailing lists
is no exception...however, that's not really what this thread was
about.

Most of this thread has been about what non-decision-making role
should IRC play, if any, for a podling project?  The XAP folks already
knew decisions shouldn't be made on IRC; they were talking about
whether regular, open IRC discussions could be helpful.  Based on this
thread (particularly Noel and Geir's thoughts, which I steal much of
below) and other recent threads, here's what I would propose also be
doc'd:

"IRC can be used by a podling to bring new people up to speed (e.g.
Q&A between available committers and interested users/contributors),
although such sessions should be archived and made available to those
not able to attend.  However, using IRC as a means to conduct
development/architecture discussions is discouraged.  Even with the
best intentions, experience has shown that it is difficult to maintain
such discussions without implicit decisions being made in the
process."

Thoughts?

Cliff

On 7/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:

Jean-


> Given this paragraph in the committers guide [1]:
>
> > Everything -- but everything-- inside the Apache world occurs or is 
reflected in email. As some people say, 'If it isn't in my email, it didn't happen.'
>
> Would adding this sentence to the end help?
>
>Decisions only get made on Apache mail lists -- not anywhere
>off list, such as IRC, IM, or private emails.


yes! I like it! I'd like to provide a patch, or go ahead if you have
"write" rights.

-Matthias

> > btw. 404 for:
> > http://incubator.apache.org/howtoparticipate.html
>
> oof! some post-docathon moldly links need to be cleaned up. thanks for
> pointing it out.
>
>  -jean
>
> [1] http://incubator.apache.org/guides/committer.html
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Matthias Wessendorf]

Jean-



Given this paragraph in the committers guide [1]:

> Everything -- but everything-- inside the Apache world occurs or is reflected 
in email. As some people say, 'If it isn't in my email, it didn't happen.'

Would adding this sentence to the end help?

   Decisions only get made on Apache mail lists -- not anywhere
   off list, such as IRC, IM, or private emails.



yes! I like it! I'd like to provide a patch, or go ahead if you have
"write" rights.

-Matthias


> btw. 404 for:
> http://incubator.apache.org/howtoparticipate.html

oof! some post-docathon moldly links need to be cleaned up. thanks for
pointing it out.

 -jean

[1] http://incubator.apache.org/guides/committer.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Justin Erenkrantz]

On 7/11/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote:

Given this paragraph in the committers guide [1]:

> Everything -- but everything-- inside the Apache world occurs or is reflected 
in email. As some people say, 'If it isn't in my email, it didn't happen.'

Would adding this sentence to the end help?

   Decisions only get made on Apache mail lists -- not anywhere
   off list, such as IRC, IM, or private emails.


+1.  Can't hurt to be more explicit.  Would rephrase it to be "on
public Apache mail lists".  (Unless it's personal or security-related,
it doesn't belong on the (P)PMC list either...but that caveat doesn't
apply here in this context.)

Thanks!  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Jean T. Anderson]

Matthias Wessendorf wrote:
>> Any off-list communication is a potential problem, not just IRC.
> 
> sure. but IRC is much more a "problem" than IM.
> IM *mostly* is peer-peer "chat". IRC a *group* is involved.

Given this paragraph in the committers guide [1]:

> Everything -- but everything-- inside the Apache world occurs or is reflected 
> in email. As some people say, 'If it isn't in my email, it didn't happen.'

Would adding this sentence to the end help?

   Decisions only get made on Apache mail lists -- not anywhere
   off list, such as IRC, IM, or private emails.

> btw. 404 for:
> http://incubator.apache.org/howtoparticipate.html

oof! some post-docathon moldly links need to be cleaned up. thanks for
pointing it out.

 -jean

[1] http://incubator.apache.org/guides/committer.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Noel J. Bergman]

Ted Leung wrote:

> Noel J. Bergman wrote:

> > We should use our judgment to ensure a collaborative environment
> > without undue overhead.  But it would be unfair, for example, to
> > deliberately hold a vote when someone whom you know is opposed
> > is going to be off-line.

> I was just asking the question

I know.  :-)

> since a number of people seemed put out by the 72 hour limit.

People often look at the downside of rules, especially when they've been
abused by people using the letter of the rules against the spirit of the
rules.  And Leo's certainly seen that happen.

> I would say that if people are deliberately holding votes to exclude
> people with opposing opinions we have bigger problems than whether or
> not we have a hard limit on vote durations.

Agreed.  :-)

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Ted Leung]

On Jul 11, 2006, at 10:57 AM, Noel J. Bergman wrote:


I guess the bigger question is whether we ought to change the
72 hour guideline for the foundation as a whole, or make
incuabator votes a clearly noted exception.


We should use our judgment to ensure a collaborative environment  
without
undue overhead.  But it would be unfair, for example, to  
deliberately hold a

vote when someone whom you know is opposed is going to be off-line.


I was just asking the question, since a number of people seemed put  
out by the
72 hour limit.I would say that if people are deliberately holding  
votes to exclude
people with opposing opinions we have bigger problems than whether or  
not we

have a hard limit on vote durations.

Ted

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Matthias Wessendorf]

Any off-list communication is a potential problem, not just IRC.


sure. but IRC is much more a "problem" than IM.
IM *mostly* is peer-peer "chat". IRC a *group* is involved.

btw. 404 for:
http://incubator.apache.org/howtoparticipate.html


 -jean


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Jean T. Anderson]

Matthias Wessendorf wrote:
>> > Someone did point out that dev traffic is falling off while commit
>> > traffic is same or increasing.
>>
>> Yep -- and since asking about the Synapse perspective, I haven't seen
>> a persuasive argument that IRC has been a particularly positive thing
>> for them.  The key issue could be whether IRC is used as "a learning
>> tool to rapidly bring new people up to speed" (as Noel asked, and I
>> echoed, curiosity about) , or whether it is more for development
>> discussions (which I think is a dangerous move, particularly for a new
>> project).
> 
> I think we (or more correct; the Incubator PMC) should put it as an
> extra information to the guide lines, that IRC is *not* the "channel"
> to make dev. related decisions.

After the recent docathon
http://incubator.apache.org/guides/committer.html now has this:

> Everything -- but everything-- inside the Apache world occurs or is reflected 
> in email. As some people say, 'If it isn't in my email, it didn't happen.'

Any off-list communication is a potential problem, not just IRC.

 -jean


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Matthias Wessendorf]

> Someone did point out that dev traffic is falling off while commit
> traffic is same or increasing.

Yep -- and since asking about the Synapse perspective, I haven't seen
a persuasive argument that IRC has been a particularly positive thing
for them.  The key issue could be whether IRC is used as "a learning
tool to rapidly bring new people up to speed" (as Noel asked, and I
echoed, curiosity about) , or whether it is more for development
discussions (which I think is a dangerous move, particularly for a new
project).


I think we (or more correct; the Incubator PMC) should put it as an
extra information to the guide lines, that IRC is *not* the "channel"
to make dev. related decisions.

-Matthias

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Cliff Schmidt]

On 7/11/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:

This thread may be dead/resolved, in which case just ignore me.


It was only "mostly-dead"...but you've raised some good points that I
agree with.


Cliff Schmidt wrote:
> On 6/23/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> The use of e-mail as the primary means for communication is part of ASF
>> policy and philosophy, and we can certainly learn lessons from
>> projects that
>> have gone against it.  IRC tends to breed a more closed, albeit arguably
>> more integrated, community.
>>
>> That said, if IRC can be used as a learning tool to rapidly bring new
>> people
>> up to speed, and if the information gathered from those sessions is
>> preserved for others to follow up via web-site and e-mail, how do people
>> perceive that?
>
> I've never done that on a project, but I think it could be a
> reasonable thing for a project to try.  I believe the Synapse folks
> have been doing regular IRC meetings from early on.  I'd be interested
> in their perspective on the pros and cons, particularly as an
> incubating project.

Someone did point out that dev traffic is falling off while commit
traffic is same or increasing.


Yep -- and since asking about the Synapse perspective, I haven't seen
a persuasive argument that IRC has been a particularly positive thing
for them.  The key issue could be whether IRC is used as "a learning
tool to rapidly bring new people up to speed" (as Noel asked, and I
echoed, curiosity about) , or whether it is more for development
discussions (which I think is a dangerous move, particularly for a new
project).


> As a XAP mentor, I know that the committers already understand that no
> decisions will be made over IRC, that logs of each IRC will be
> immediately made available to the entire community, and that they need
> to be sensitive to any concerns from people wishing but unable to
> participate.  But, are there other thoughts from the Synapse folks or
> anyone else who has used regular IRC meetings?

I think that people can have that understanding, but I think that it
doesn't matter - it's been my experience that while people are able to
quote the letter of the law as well as the explain the reason behind it,
people unintentionally make "informal decisions" on IRC and execute on
them, all with the best of intentions.  I know i've seen it with
Geronimo, and it can be very disruptive, even though it may be accidental.

I think lots of decisions made on dev lists are the same - informal -
without the trappings of a vote or such, because many decisions are made
by "lazy consensus" - people discuss things or search for help, and then
continue down whatever modified path the group explicitly or implicitly
agreed to.


+1


In the case of XAP, I'm guessing that many of the committers are
employees or contractors/consultants of Nexaweb.  Were I a mentor, I'd
want to be sure that pre-existing development process is being
sufficiently broken up to make it an Apache community development
project, and would worry that regular IRC meetings might be confused
with periodic development meetings...


I'm not as concerned about this point.  Having a semi-monthly IRC
session to help bring new people up to speed is unlikely to be the
thing that holds back a closed development process from becoming an
open and collaborative one.

The short, sound-bite version of the advice I give companies that are
trying to transition their development process to one like Apache's
is, "commits should make sense with the context of the public dev-list
archive alone, and the dev-list should make sense with the context of
the code base alone." (there are exceptions such as bug/issue history,
etc, but that doesn't fit in the sound-bite ;-)   The idea being to
prevent potential hallway conversations or other communication from
being part of the context of the work.

The kind of IRC session that Noel was asking about is less likely to
be the problem.  However, I agree with your concerns people
unintentionally making informal decisions on development-oriented IRC
meetings.

Cliff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Noel J. Bergman]

Ted Leung wrote:

> In this case, we had several weeks of discussion on Heraldry,
> including some F2F conversations at ApacheCon EU, so 72 hours
> doesn't seem like a big deal to me.

Nor me.

> I guess the bigger question is whether we ought to change the
> 72 hour guideline for the foundation as a whole, or make
> incuabator votes a clearly noted exception.

We should use our judgment to ensure a collaborative environment without
undue overhead.  But it would be unfair, for example, to deliberately hold a
vote when someone whom you know is opposed is going to be off-line.

The Board has declared that 72 hours must pass between an ACK for PMC
membership and when the person is officially a member of the PMC.  That is
their perogative, since the Board determines whom is on a PMC.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Roy T. Fielding]

On Jul 11, 2006, at 10:21 AM, Ted Leung wrote:
In this case, we had several weeks of discussion on Heraldry,  
including some F2F
conversations at ApacheCon EU, so 72 hours doesn't seem like a big  
deal to me.
If people want to extend the voting period, I've no problem with  
that.   I guess the bigger
question is whether we ought to change the 72 hour guideline for  
the foundation as a whole, or

make incuabator votes a clearly noted exception.


No.  No vote at Apache should require more than 72 hours.  Everyone does
not need to vote.  We are a distributed organization that cannot afford
to be hamstrung just because a few people may happen to be busy or on
vacation at the time.  The minimal quorum constraint was specifically
designed to prevent "volunteer variances" from effecting our ability
to make decisions.

Roy  (+0 for acceptance of Heraldry)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Ted Leung]

On Jul 11, 2006, at 7:02 AM, Leo Simons wrote:


On Tue, Jul 11, 2006 at 12:50:44PM +0100, robert burrell donkin wrote:
On 7/10/06, robert burrell donkin <[EMAIL PROTECTED]>  
wrote:

On 7/10/06, Ted Leung <[EMAIL PROTECTED]> wrote:



In keeping with Apache practice, I'd like to allow 72 hours or so for
the vote to close, so please vote by 11:59PST on Thursday July  
13th.


(this duration seems just a little bit on the short side to me:  
it's good

to give everyone a chance to cast a vote. not sure whether there's a
consensus about the right duration for these votes. but it's  
probably best
to kick off something on another thread rather than disrupt this  
vote...)


is 72 hours the right length for an acceptance vote?


I expect that is a difficult question :-)

I've personally always been annoyed with these kinds of limits. I  
just don't
like how it puts some sort of "pressure" on volunteers. OTOH, when  
there has
been plenty of discussion/soul searching beforehand and the vote is  
just a
formalisation of a pre-existing consensus 72 hours is plenty.  
Harmony has grown
into "72 hours or until all with a binding vote have cast theirs,  
or longer if
someone asks for an extension" and its a suitable comprimise there.  
Over at this
other project that is now dead at some point we made it "1 week"  
for everything
to avoid things getting pushed through over an independence day  
weekend (for

example).


In this case, we had several weeks of discussion on Heraldry,  
including some F2F
conversations at ApacheCon EU, so 72 hours doesn't seem like a big  
deal to me.
If people want to extend the voting period, I've no problem with  
that.   I guess the bigger
question is whether we ought to change the 72 hour guideline for the  
foundation as a whole, or

make incuabator votes a clearly noted exception.

Ted

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Samisa Abeysinghe]

Sanjiva Weerawarana wrote:


On Tue, 2006-07-11 at 12:50 +0100, robert burrell donkin wrote:
 


is 72 hours the right length for an acceptance vote?
   



I'd prefer a bit more time .. like the time for graduation etc. - these
are BIG decisions and unlike code decisions hard to revert. As such I
think we should not rush things. 
 

+1. At least a week, which happens to include a weekend, leaving room to 
get into more depth.


Samisa...


Sometimes forcing the vote forces people to do the due diligence they
were unable to do during the discussion period .. not ideal but reality
IMO.

Sanjiva.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DOAP files for Podling

[Matthias Wessendorf]

cool!

On 7/11/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

If anyone who uses Maven is interested I can whip off a plugin to
create a DOAP file from a POM so that they don't have to maintain
both files. For any elements missing in the POM that might be
required (don't know, haven't looked) the information can be placed
in standard properties for the purpose of creating DOAP files. Any
missing elements can eventually be added to the POM model.

Jason.

On 10 Jul 06, at 8:56 PM 10 Jul 06, Matthias Wessendorf wrote:

> Hey,
>
> the website requirements say nothing about a DOAP file for the
> Podlings. With the DOAP file a Polding is able to be listed on
> "projects.a.o"
>
> To me, there *shouldn't* be a DOAP file (see [1]) for a Podling, since
> a Podling is not a full ASF project. For adffaces (aka Trinidad)
> Podling, I created one, but I prefere not to *publish* that
> information on "projects.a.o"
>
> What is the exact rule on that?
>
> Greetings,
> Matthias
>
> [1] http://projects.apache.org/create.html
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Jason van Zyl
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Matthias Wessendorf

futher stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept Heraldry into the Incubator

[Danese Cooper]

Not that I get a vote...but I'd +1 it also.

Danese

On 7/10/06, Ted Leung <[EMAIL PROTECTED]> wrote:

It seems like the discussion on Heraldry has died down, so I'd like
to call for a VOTE on accepting Heraldry into the incubator.

In keeping with Apache practice, I'd like to allow 72 hours or so for
the vote to close, so please vote by 11:59PST on Thursday July 13th.

The current proposal is here:  , and I've included the full text below.

My vote is +1

Ted

--
= Proposal =
This is a proposal to create a project within the Apache Software
Foundation to develop technologies around the emerging user-centric
identity space.  The project would utilize Yadis [1] for URL/XRI-
based service discovery and OpenID [2] for web based single-sign-on
and the basis of exchanging profile data.  Yadis is currently being
standardized within OASIS as part of the XRI effort, within a TC
committed to creating royalty-free work, and OpenID has emerged as a
de-facto specification.  The two initial components of the project,
downloadable perspective, would be an Identity Provider application
and libraries in various languages that implement Yadis and OpenID.
The initial goal would be to both provide an out-of-the-box
application as well as the required libraries for other developers to
integrate Yadis and OpenID into their existing applications.

To provide some background, the Higgins Project is being actively
developed within Eclipse and is a framework that will enable users
and enterprises to integrate identity, profile, and relationship
information across multiple systems. Using context providers,
existing and new systems such as directories, collaboration spaces,
and communications technologies (e.g. Microsoft/IBM WS-*, LDAP,
email, IM, etc.) can be plugged into the Higgins framework.
Applications written to the Higgins API can virtually integrate the
identity, profile, and relationship information across these
heterogeneous systems.  They current have integration with
Microsoft's CardSpace and we'll be working with them over the next
few months to add support for OpenID.  It hasn't yet been determined,
nor does it need to be right now, if the code to tie OpenID into
Higgins will live within Apache or Eclipse.


= Rationale =
While identity systems such as X.509 have existed for many years, and
more recently SAML and the Liberty Alliance framework, only within
the past two years has there been a true emergence of user-centric
technologies.  Pursuant to Kim Cameron's laws of identity,
technologies such as LID, Yadis, OpenID, and Sxip were defined to put
control of a person's digital identity back into their own hands.

Both Yadis and OpenID have reached a point where they have millions
of users and a strong community backing.  On May 28th 2006, Brion
Vibber of WikiMedia announced in a Google Tech Talk that WikiPedia
would support both of them within the following month.  This sort of
broad adoption and traction has not been seen with other technologies
of this kind in this space.

By bringing these technologies to one place, these communities will
have a place to fully converge and continue the development of
interoperable implementations.  Additionally, by working with the
Higgins Project, ASF will be able to provide a foundation where a
person can use one or more digital identities consistently across
blogs, eCommerce sites, and portals as well as even high-risk
transactions via their desktop computer.

Currently Apache does not offer any project such as the one being
proposed.  Integration with projects such as Lenya would definitely
be encouraged.

= Initial Goals =
  * Expansion of Yadis and OpenID libraries into additional languages
beyond the existing Python, Ruby, Perl, and PHP libraries
  * OpenID authentication specification revision to fix known
security considerations, investigate compatibility with the DIX IETF
proposal, describe Yadis integration, and allow either an URL or XRI
be used as the End User's Identifier
  * Continue the development of a data transfer protocol on top of
OpenID to allow the exchange of profile data as well as other secure
messages
  * Investigate existing mechanisms for profile exchange, namely Sxip
2.0 and SAML, and investigate how they would be layered atop OpenID
  * Integration of the OpenID Authentication protocol with the
Higgins framework to provide desktop integration
  * Extension of OpenID to support non-browser based authentication
use cases.  ie authentication to a Subversion server, creation of
mod_authnz_openid, using your OpenID Identity without modifying the
svn client-side tool

= Known Risks =

== Commercial Interest ==
  * Many companies are currently working to build businesses
supported on top of these technologies.  As part of the code
contributions, VeriSign will contribute source to their Personal
Identity Provider to provide a complete base with both libraries and
a s

RE: [VOTE] Accept Heraldry into the Incubator

[Noel J. Bergman]

+1

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Noel J. Bergman]

robert burrell donkin wrote:

> is 72 hours the right length for an acceptance vote?

I wouldn't do it over a week, especially a long weekend.  And if very few
PMC members have voted, I might post a reminder to vote rather than close a
vote with a minimum of voters.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Leo Simons]

On Tue, Jul 11, 2006 at 12:50:44PM +0100, robert burrell donkin wrote:
> On 7/10/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> >On 7/10/06, Ted Leung <[EMAIL PROTECTED]> wrote:
> 
> 
> In keeping with Apache practice, I'd like to allow 72 hours or so for
> >> the vote to close, so please vote by 11:59PST on Thursday July 13th.
> >
> >(this duration seems just a little bit on the short side to me: it's good
> >to give everyone a chance to cast a vote. not sure whether there's a
> >consensus about the right duration for these votes. but it's probably best
> >to kick off something on another thread rather than disrupt this vote...)
> 
> is 72 hours the right length for an acceptance vote?

I expect that is a difficult question :-)

I've personally always been annoyed with these kinds of limits. I just don't
like how it puts some sort of "pressure" on volunteers. OTOH, when there has
been plenty of discussion/soul searching beforehand and the vote is just a
formalisation of a pre-existing consensus 72 hours is plenty. Harmony has grown
into "72 hours or until all with a binding vote have cast theirs, or longer if
someone asks for an extension" and its a suitable comprimise there. Over at this
other project that is now dead at some point we made it "1 week" for everything
to avoid things getting pushed through over an independence day weekend (for
example).

LSD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept Heraldry into the Incubator

[Ben Laurie]

On 7/10/06, Ted Leung <[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It seems like the discussion on Heraldry has died down, so I'd like
to call for a VOTE on accepting Heraldry into the incubator.

In keeping with Apache practice, I'd like to allow 72 hours or so for
the vote to close, so please vote by 11:59PST on Thursday July 13th.

The current proposal is here:  , and I've included the full text below.

My vote is +1


In case it isn't obvious: +1

Cheers,

Ben.



Ted

- --
= Proposal =
This is a proposal to create a project within the Apache Software
Foundation to develop technologies around the emerging user-centric
identity space.  The project would utilize Yadis [1] for URL/XRI-
based service discovery and OpenID [2] for web based single-sign-on
and the basis of exchanging profile data.  Yadis is currently being
standardized within OASIS as part of the XRI effort, within a TC
committed to creating royalty-free work, and OpenID has emerged as a
de-facto specification.  The two initial components of the project,
downloadable perspective, would be an Identity Provider application
and libraries in various languages that implement Yadis and OpenID.
The initial goal would be to both provide an out-of-the-box
application as well as the required libraries for other developers to
integrate Yadis and OpenID into their existing applications.

To provide some background, the Higgins Project is being actively
developed within Eclipse and is a framework that will enable users
and enterprises to integrate identity, profile, and relationship
information across multiple systems. Using context providers,
existing and new systems such as directories, collaboration spaces,
and communications technologies (e.g. Microsoft/IBM WS-*, LDAP,
email, IM, etc.) can be plugged into the Higgins framework.
Applications written to the Higgins API can virtually integrate the
identity, profile, and relationship information across these
heterogeneous systems.  They current have integration with
Microsoft's CardSpace and we'll be working with them over the next
few months to add support for OpenID.  It hasn't yet been determined,
nor does it need to be right now, if the code to tie OpenID into
Higgins will live within Apache or Eclipse.


= Rationale =
While identity systems such as X.509 have existed for many years, and
more recently SAML and the Liberty Alliance framework, only within
the past two years has there been a true emergence of user-centric
technologies.  Pursuant to Kim Cameron's laws of identity,
technologies such as LID, Yadis, OpenID, and Sxip were defined to put
control of a person's digital identity back into their own hands.

Both Yadis and OpenID have reached a point where they have millions
of users and a strong community backing.  On May 28th 2006, Brion
Vibber of WikiMedia announced in a Google Tech Talk that WikiPedia
would support both of them within the following month.  This sort of
broad adoption and traction has not been seen with other technologies
of this kind in this space.

By bringing these technologies to one place, these communities will
have a place to fully converge and continue the development of
interoperable implementations.  Additionally, by working with the
Higgins Project, ASF will be able to provide a foundation where a
person can use one or more digital identities consistently across
blogs, eCommerce sites, and portals as well as even high-risk
transactions via their desktop computer.

Currently Apache does not offer any project such as the one being
proposed.  Integration with projects such as Lenya would definitely
be encouraged.

= Initial Goals =
  * Expansion of Yadis and OpenID libraries into additional languages
beyond the existing Python, Ruby, Perl, and PHP libraries
  * OpenID authentication specification revision to fix known
security considerations, investigate compatibility with the DIX IETF
proposal, describe Yadis integration, and allow either an URL or XRI
be used as the End User's Identifier
  * Continue the development of a data transfer protocol on top of
OpenID to allow the exchange of profile data as well as other secure
messages
  * Investigate existing mechanisms for profile exchange, namely Sxip
2.0 and SAML, and investigate how they would be layered atop OpenID
  * Integration of the OpenID Authentication protocol with the
Higgins framework to provide desktop integration
  * Extension of OpenID to support non-browser based authentication
use cases.  ie authentication to a Subversion server, creation of
mod_authnz_openid, using your OpenID Identity without modifying the
svn client-side tool

= Known Risks =

== Commercial Interest ==
  * Many companies are currently working to build businesses
supported on top of these technologies.  As part of the code
contributions, VeriSign will contribute source to their Personal
Identity Provider to provide

[VOTE] Accept Heraldry into the Incubator

[Ted Leung]

It seems like the discussion on Heraldry has died down, so I'd like  
to call for a VOTE on accepting Heraldry into the incubator.


In keeping with Apache practice, I'd like to allow 72 hours or so for  
the vote to close, so please vote by 11:59PST on Thursday July 13th.


The current proposal is here:  , and I've included the full text below.


My vote is +1

Ted

--
= Proposal =
This is a proposal to create a project within the Apache Software  
Foundation to develop technologies around the emerging user-centric  
identity space.  The project would utilize Yadis [1] for URL/XRI- 
based service discovery and OpenID [2] for web based single-sign-on  
and the basis of exchanging profile data.  Yadis is currently being  
standardized within OASIS as part of the XRI effort, within a TC  
committed to creating royalty-free work, and OpenID has emerged as a  
de-facto specification.  The two initial components of the project,  
downloadable perspective, would be an Identity Provider application  
and libraries in various languages that implement Yadis and OpenID.   
The initial goal would be to both provide an out-of-the-box  
application as well as the required libraries for other developers to  
integrate Yadis and OpenID into their existing applications.


To provide some background, the Higgins Project is being actively  
developed within Eclipse and is a framework that will enable users  
and enterprises to integrate identity, profile, and relationship  
information across multiple systems. Using context providers,  
existing and new systems such as directories, collaboration spaces,  
and communications technologies (e.g. Microsoft/IBM WS-*, LDAP,  
email, IM, etc.) can be plugged into the Higgins framework.  
Applications written to the Higgins API can virtually integrate the  
identity, profile, and relationship information across these  
heterogeneous systems.  They current have integration with  
Microsoft's CardSpace and we'll be working with them over the next  
few months to add support for OpenID.  It hasn't yet been determined,  
nor does it need to be right now, if the code to tie OpenID into  
Higgins will live within Apache or Eclipse.



= Rationale =
While identity systems such as X.509 have existed for many years, and  
more recently SAML and the Liberty Alliance framework, only within  
the past two years has there been a true emergence of user-centric  
technologies.  Pursuant to Kim Cameron’s laws of identity,  
technologies such as LID, Yadis, OpenID, and Sxip were defined to put  
control of a person’s digital identity back into their own hands.


Both Yadis and OpenID have reached a point where they have millions  
of users and a strong community backing.  On May 28th 2006, Brion  
Vibber of WikiMedia announced in a Google Tech Talk that WikiPedia  
would support both of them within the following month.  This sort of  
broad adoption and traction has not been seen with other technologies  
of this kind in this space.


By bringing these technologies to one place, these communities will  
have a place to fully converge and continue the development of  
interoperable implementations.  Additionally, by working with the  
Higgins Project, ASF will be able to provide a foundation where a  
person can use one or more digital identities consistently across  
blogs, eCommerce sites, and portals as well as even high-risk  
transactions via their desktop computer.


Currently Apache does not offer any project such as the one being  
proposed.  Integration with projects such as Lenya would definitely  
be encouraged.


= Initial Goals =
 * Expansion of Yadis and OpenID libraries into additional languages  
beyond the existing Python, Ruby, Perl, and PHP libraries
 * OpenID authentication specification revision to fix known  
security considerations, investigate compatibility with the DIX IETF  
proposal, describe Yadis integration, and allow either an URL or XRI  
be used as the End User’s Identifier
 * Continue the development of a data transfer protocol on top of  
OpenID to allow the exchange of profile data as well as other secure  
messages
 * Investigate existing mechanisms for profile exchange, namely Sxip  
2.0 and SAML, and investigate how they would be layered atop OpenID
 * Integration of the OpenID Authentication protocol with the  
Higgins framework to provide desktop integration
 * Extension of OpenID to support non-browser based authentication  
use cases.  ie authentication to a Subversion server, creation of  
mod_authnz_openid, using your OpenID Identity without modifying the  
svn client-side tool


= Known Risks =

== Commercial Interest ==
 * Many companies are currently working to build businesses  
supported on top of these technologies.  As part of the code  
contributions, VeriSign will contribute source to their Personal  
Identity Provider to provide a complete base with both

Re: [VOTE] Accept Heraldry into the Incubator

[Ben Laurie]

On 7/10/06, Ted Leung <[EMAIL PROTECTED]> wrote:

It seems like the discussion on Heraldry has died down, so I'd like
to call for a VOTE on accepting Heraldry into the incubator.

In keeping with Apache practice, I'd like to allow 72 hours or so for
the vote to close, so please vote by 11:59PST on Thursday July 13th.

The current proposal is here:  , and I've included the full text below.

My vote is +1


In case it isn't obvious, mine is also +1.



Ted

--
= Proposal =
This is a proposal to create a project within the Apache Software
Foundation to develop technologies around the emerging user-centric
identity space.  The project would utilize Yadis [1] for URL/XRI-
based service discovery and OpenID [2] for web based single-sign-on
and the basis of exchanging profile data.  Yadis is currently being
standardized within OASIS as part of the XRI effort, within a TC
committed to creating royalty-free work, and OpenID has emerged as a
de-facto specification.  The two initial components of the project,
downloadable perspective, would be an Identity Provider application
and libraries in various languages that implement Yadis and OpenID.
The initial goal would be to both provide an out-of-the-box
application as well as the required libraries for other developers to
integrate Yadis and OpenID into their existing applications.

To provide some background, the Higgins Project is being actively
developed within Eclipse and is a framework that will enable users
and enterprises to integrate identity, profile, and relationship
information across multiple systems. Using context providers,
existing and new systems such as directories, collaboration spaces,
and communications technologies (e.g. Microsoft/IBM WS-*, LDAP,
email, IM, etc.) can be plugged into the Higgins framework.
Applications written to the Higgins API can virtually integrate the
identity, profile, and relationship information across these
heterogeneous systems.  They current have integration with
Microsoft's CardSpace and we'll be working with them over the next
few months to add support for OpenID.  It hasn't yet been determined,
nor does it need to be right now, if the code to tie OpenID into
Higgins will live within Apache or Eclipse.


= Rationale =
While identity systems such as X.509 have existed for many years, and
more recently SAML and the Liberty Alliance framework, only within
the past two years has there been a true emergence of user-centric
technologies.  Pursuant to Kim Cameron's laws of identity,
technologies such as LID, Yadis, OpenID, and Sxip were defined to put
control of a person's digital identity back into their own hands.

Both Yadis and OpenID have reached a point where they have millions
of users and a strong community backing.  On May 28th 2006, Brion
Vibber of WikiMedia announced in a Google Tech Talk that WikiPedia
would support both of them within the following month.  This sort of
broad adoption and traction has not been seen with other technologies
of this kind in this space.

By bringing these technologies to one place, these communities will
have a place to fully converge and continue the development of
interoperable implementations.  Additionally, by working with the
Higgins Project, ASF will be able to provide a foundation where a
person can use one or more digital identities consistently across
blogs, eCommerce sites, and portals as well as even high-risk
transactions via their desktop computer.

Currently Apache does not offer any project such as the one being
proposed.  Integration with projects such as Lenya would definitely
be encouraged.

= Initial Goals =
  * Expansion of Yadis and OpenID libraries into additional languages
beyond the existing Python, Ruby, Perl, and PHP libraries
  * OpenID authentication specification revision to fix known
security considerations, investigate compatibility with the DIX IETF
proposal, describe Yadis integration, and allow either an URL or XRI
be used as the End User's Identifier
  * Continue the development of a data transfer protocol on top of
OpenID to allow the exchange of profile data as well as other secure
messages
  * Investigate existing mechanisms for profile exchange, namely Sxip
2.0 and SAML, and investigate how they would be layered atop OpenID
  * Integration of the OpenID Authentication protocol with the
Higgins framework to provide desktop integration
  * Extension of OpenID to support non-browser based authentication
use cases.  ie authentication to a Subversion server, creation of
mod_authnz_openid, using your OpenID Identity without modifying the
svn client-side tool

= Known Risks =

== Commercial Interest ==
  * Many companies are currently working to build businesses
supported on top of these technologies.  As part of the code
contributions, VeriSign will contribute source to their Personal
Identity Provider to provide a complete base with both libraries and
a sample 

Re: [VOTE] Accept Heraldry into the Incubator

[Leo Simons]

+1

(and what he said applies to me too)

Leo

On Tue, Jul 11, 2006 at 07:41:20AM -0400, Geir Magnusson Jr wrote:
> +1
> 
> (And I'll note now that I'm interested in participating, although can't
> commit the time to be a mentor right now.)
> 
> Ted Leung wrote:
> > It seems like the discussion on Heraldry has died down, so I'd like to
> > call for a VOTE on accepting Heraldry into the incubator.
> > 
> > In keeping with Apache practice, I'd like to allow 72 hours or so for
> > the vote to close, so please vote by 11:59PST on Thursday July 13th.
> > 
> > The current proposal is here: 
> > , and I've
> > included the full text below.
> > 
> > My vote is +1
> > 
> > Ted
> > 
> > --
> > = Proposal =
> > This is a proposal to create a project within the Apache Software
> > Foundation to develop technologies around the emerging user-centric
> > identity space.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extensible Ajax Platform (XAP) Project Update

[Geir Magnusson Jr]

This thread may be dead/resolved, in which case just ignore me.

Cliff Schmidt wrote:
> On 6/23/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> The use of e-mail as the primary means for communication is part of ASF
>> policy and philosophy, and we can certainly learn lessons from
>> projects that
>> have gone against it.  IRC tends to breed a more closed, albeit arguably
>> more integrated, community.
>>
>> That said, if IRC can be used as a learning tool to rapidly bring new
>> people
>> up to speed, and if the information gathered from those sessions is
>> preserved for others to follow up via web-site and e-mail, how do people
>> perceive that?
> 
> I've never done that on a project, but I think it could be a
> reasonable thing for a project to try.  I believe the Synapse folks
> have been doing regular IRC meetings from early on.  I'd be interested
> in their perspective on the pros and cons, particularly as an
> incubating project.

Someone did point out that dev traffic is falling off while commit
traffic is same or increasing.

> 
> As a XAP mentor, I know that the committers already understand that no
> decisions will be made over IRC, that logs of each IRC will be
> immediately made available to the entire community, and that they need
> to be sensitive to any concerns from people wishing but unable to
> participate.  But, are there other thoughts from the Synapse folks or
> anyone else who has used regular IRC meetings?

I think that people can have that understanding, but I think that it
doesn't matter - it's been my experience that while people are able to
quote the letter of the law as well as the explain the reason behind it,
people unintentionally make "informal decisions" on IRC and execute on
them, all with the best of intentions.  I know i've seen it with
Geronimo, and it can be very disruptive, even though it may be accidental.

I think lots of decisions made on dev lists are the same - informal -
without the trappings of a vote or such, because many decisions are made
by "lazy consensus" - people discuss things or search for help, and then
continue down whatever modified path the group explicitly or implicitly
agreed to.

In the case of XAP, I'm guessing that many of the committers are
employees or contractors/consultants of Nexaweb.  Were I a mentor, I'd
want to be sure that pre-existing development process is being
sufficiently broken up to make it an Apache community development
project, and would worry that regular IRC meetings might be confused
with periodic development meetings...

geir




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]

[Geir Magnusson Jr]

David N. Welton wrote:
> robert burrell donkin wrote:
>> ... an idea and
>> community ...
> 
>> i was wondering whether we might widen the general incubator list to
>> include
>> ideas for new projects provided that they are prefixed by [idea] in the
>> subject so that anyone who's not interested can ignore.
> 
> It would be difficult to bring an idea accompanied by a community.  The
> community bit usually happens when there is working code and people pick
> it up and start using it.

Not always.  Geronimo started without code, and so did Harmony.
Granted, we started with clear specs and had some ideas about code
reuse, but still...

As another counter-example, Jakarta Commons was an idea several of us
had, which was more important than the seed code, because we were
rallying around the idea, not the specific seeds.

So I do believe that we should [continue to] be open to motivated people
with just an idea...

And as to Robert's post, I don't see why people just can't throw them
out here.  Having too much [EMAIL PROTECTED] traffic because of new
ideas people are discussing would be an excellent problem to have.

geir


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept Heraldry into the Incubator

[Geir Magnusson Jr]

+1

(And I'll note now that I'm interested in participating, although can't
commit the time to be a mentor right now.)

Ted Leung wrote:
> It seems like the discussion on Heraldry has died down, so I'd like to
> call for a VOTE on accepting Heraldry into the incubator.
> 
> In keeping with Apache practice, I'd like to allow 72 hours or so for
> the vote to close, so please vote by 11:59PST on Thursday July 13th.
> 
> The current proposal is here: 
> , and I've
> included the full text below.
> 
> My vote is +1
> 
> Ted
> 
> --
> = Proposal =
> This is a proposal to create a project within the Apache Software
> Foundation to develop technologies around the emerging user-centric
> identity space.  The project would utilize Yadis [1] for URL/XRI-based
> service discovery and OpenID [2] for web based single-sign-on and the
> basis of exchanging profile data.  Yadis is currently being standardized
> within OASIS as part of the XRI effort, within a TC committed to
> creating royalty-free work, and OpenID has emerged as a de-facto
> specification.  The two initial components of the project, downloadable
> perspective, would be an Identity Provider application and libraries in
> various languages that implement Yadis and OpenID.  The initial goal
> would be to both provide an out-of-the-box application as well as the
> required libraries for other developers to integrate Yadis and OpenID
> into their existing applications.
> 
> To provide some background, the Higgins Project is being actively
> developed within Eclipse and is a framework that will enable users and
> enterprises to integrate identity, profile, and relationship information
> across multiple systems. Using context providers, existing and new
> systems such as directories, collaboration spaces, and communications
> technologies (e.g. Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be
> plugged into the Higgins framework. Applications written to the Higgins
> API can virtually integrate the identity, profile, and relationship
> information across these heterogeneous systems.  They current have
> integration with Microsoft's CardSpace and we'll be working with them
> over the next few months to add support for OpenID.  It hasn't yet been
> determined, nor does it need to be right now, if the code to tie OpenID
> into Higgins will live within Apache or Eclipse.
> 
> 
> = Rationale =
> While identity systems such as X.509 have existed for many years, and
> more recently SAML and the Liberty Alliance framework, only within the
> past two years has there been a true emergence of user-centric
> technologies.  Pursuant to Kim Camerons laws of identity, technologies
> such as LID, Yadis, OpenID, and Sxip were defined to put control of a
> persons digital identity back into their own hands.
> 
> Both Yadis and OpenID have reached a point where they have millions of
> users and a strong community backing.  On May 28th 2006, Brion Vibber of
> WikiMedia announced in a Google Tech Talk that WikiPedia would support
> both of them within the following month.  This sort of broad adoption
> and traction has not been seen with other technologies of this kind in
> this space.
> 
> By bringing these technologies to one place, these communities will have
> a place to fully converge and continue the development of interoperable
> implementations.  Additionally, by working with the Higgins Project, ASF
> will be able to provide a foundation where a person can use one or more
> digital identities consistently across blogs, eCommerce sites, and
> portals as well as even high-risk transactions via their desktop computer.
> 
> Currently Apache does not offer any project such as the one being
> proposed.  Integration with projects such as Lenya would definitely be
> encouraged.
> 
> = Initial Goals =
>  * Expansion of Yadis and OpenID libraries into additional languages
> beyond the existing Python, Ruby, Perl, and PHP libraries
>  * OpenID authentication specification revision to fix known security
> considerations, investigate compatibility with the DIX IETF proposal,
> describe Yadis integration, and allow either an URL or XRI be used as
> the End Users Identifier
>  * Continue the development of a data transfer protocol on top of OpenID
> to allow the exchange of profile data as well as other secure messages
>  * Investigate existing mechanisms for profile exchange, namely Sxip 2.0
> and SAML, and investigate how they would be layered atop OpenID
>  * Integration of the OpenID Authentication protocol with the Higgins
> framework to provide desktop integration
>  * Extension of OpenID to support non-browser based authentication use
> cases.  ie authentication to a Subversion server, creation of
> mod_authnz_openid, using your OpenID Identity without modifying the svn
> client-side tool
> 
> = Known Risks =
> 
> == Commercial Interest ==
>  * Many companies are currently working to buil

Re: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[Sanjiva Weerawarana]

On Tue, 2006-07-11 at 12:50 +0100, robert burrell donkin wrote:
> 
> is 72 hours the right length for an acceptance vote?

I'd prefer a bit more time .. like the time for graduation etc. - these
are BIG decisions and unlike code decisions hard to revert. As such I
think we should not rush things. 

Sometimes forcing the vote forces people to do the due diligence they
were unable to do during the discussion period .. not ideal but reality
IMO.

Sanjiva.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [documentation][DRAFT] Proposal Guide

[robert burrell donkin]

On 7/5/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:


what i came to pull together the material for the proposal template, i
found that it didn't really fit into the annotation template format
originally conceived. so, here is a first draft of a guide for proposals
containing a template. it's rough and ready but the polish can be applied
later.

the heraldry proposal works quite well for me so the format is a little
closer to the less structured format than the original discussion. i think
that this is good since it produces better prose and less box ticking. those
who have objections to this less structure approach should probably jump in
here (rather than in line).

comments in line, please. it's a long post so please cut everything which
is not relevant to the comment.



anyone have any improvements or comments?

(otherwise i'll commit something similar in the next day or two)

- robert

Guide For Proposal Creation

=

Abstract


This document is descriptive not normative. It describes ways to go about
drawing up a proposal for submission. It is not an inflexible standard but
does respresent a consensus condensed from previous discussions on the
incubator general list.

Background
-

Entry to the incubator is a democractic process. The incubator pmc votes
on whether to accept or not. The proposal is the document upon which the pmc
votes. So, though it's not necessary or sufficient to have a good proposal,
a good proposal document will increase the chances of a positive result.

The proposal is (in some ways) a manifesto. It should shape the evolution
of the product at apache. A lot of the information contained should be
included in the initial project website.

Help Wanted!
---
Help to improve the system by posting patching for this document to the
incubator section of JIRA.


Formulating A Proposal
=

Start by RTFM. The Entry To The incubator is a good place to start this
process.

Spend some time reviewing the mailing lists and subscribe to
[EMAIL PROTECTED] The mailing lists are the canonical form of
communication and
decision making at apache. The documentation represents an attempt to
codify the consensus formed on list.

Before drawing up a lengthy proposal, recruit a champion. [links to other
documentation explaning role of champion] The champion knows how apache work

and should be able to navigate the process.

Review recent proposals [links to the wiki] and how they have been
received.

The incoming community needs to work together before presenting this
proposal to
the incubator. Think about goals and about the reasons for coming to
apache.

Once the preparatory work is done, the proposal should be presented to the
incubator.  This is done by posting the proposal
in plain text in a email whose subject is prefixed with [PROPOSAL].

Expect to work on improving the template on list after presenting it. The
wiki is an excellent way to develop a proposal so consider creating a wiki
page containing the same content and supplying a link. Interested parties
may wish to add themselves to the watch list for the page so that received
email notifications
when the page is changed.

When the proposal seems finish and some sort of consensus has emerged, the
proposal can be put to the vote.

Proposal Template
==
The aim of presenting a template with examples and comments is
educational. Proposals are not required to adopt this format. If you can see
a better way: great.

Every proposal is different. There may be sections which don't seem to be
useful. It's fine to miss them out and add new ones that the proposal seems
to need.

Abstract



What is the proposed project? This is a short descriptive summary of the
project. Ideally one sentence in length.

It is important that the technical vision for an open source project can
be communicated in a short paragraph. This paragraph will most like be used
for the board resolution used to create the official project upon
graduation, may be used as the first paragraph on the web site and as the
DOAP description.


Examples:
  Geronimo will be a J2EE compliant container.
  Heraldry will develop technologies around the emerging user-centric
identity space.
  Yoko will be a CORBA server.

Proposal
-

A lengthier description of the proposal. Should be reasonably declarative.
More discursive material can be included in later sections.


Background
-

For some projects, it may be useful to provide context. If you proposal
contains words that  for which there is not a consensus definition, please
explain what you mean by them. if the problem  domain is likely to be
unfamiliar to many then please outline the domain.

This content should be capable of being safely ignored by any domain
experts.

This material should probably find an eventual home on the project
website.


Rationale
-

Why does this project need to exist and 

Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]

[robert burrell donkin]

On 7/10/06, robert burrell donkin <[EMAIL PROTECTED]> wrote:


On 7/10/06, Ted Leung <[EMAIL PROTECTED]> wrote:





In keeping with Apache practice, I'd like to allow 72 hours or so for

> the vote to close, so please vote by 11:59PST on Thursday July 13th.
>

(this duration seems just a little bit on the short side to me: it's good
to give everyone a chance to cast a vote. not sure whether there's a
consensus about the right duration for these votes. but it's probably best
to kick off something on another thread rather than disrupt this vote...)



is 72 hours the right length for an acceptance vote?

- robert

Re: DOAP files for Podling

[robert burrell donkin]

On 7/11/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:


Hi,

On 7/11/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> If anyone who uses Maven is interested I can whip off a plugin to
> create a DOAP file from a POM so that they don't have to maintain
> both files.

That would be nice!



+1

- robert

Re: DOAP files for Podling

[Jukka Zitting]

Hi,

On 7/11/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:

If anyone who uses Maven is interested I can whip off a plugin to
create a DOAP file from a POM so that they don't have to maintain
both files.


That would be nice!

BR,

Jukka Zitting

--
Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: DOAP files for Podling

[Jason van Zyl]

Hi,

If anyone who uses Maven is interested I can whip off a plugin to  
create a DOAP file from a POM so that they don't have to maintain  
both files. For any elements missing in the POM that might be  
required (don't know, haven't looked) the information can be placed  
in standard properties for the purpose of creating DOAP files. Any  
missing elements can eventually be added to the POM model.


Jason.

On 10 Jul 06, at 8:56 PM 10 Jul 06, Matthias Wessendorf wrote:


Hey,

the website requirements say nothing about a DOAP file for the
Podlings. With the DOAP file a Polding is able to be listed on
"projects.a.o"

To me, there *shouldn't* be a DOAP file (see [1]) for a Podling, since
a Podling is not a full ASF project. For adffaces (aka Trinidad)
Podling, I created one, but I prefere not to *publish* that
information on "projects.a.o"

What is the exact rule on that?

Greetings,
Matthias

[1] http://projects.apache.org/create.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Jason van Zyl
[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]