Re: Error on Release Download Page page ?

[John D. Ament]

On Wed, Dec 7, 2016 at 8:52 PM sebb  wrote:

> On 8 December 2016 at 01:38, John D. Ament  wrote:
> > For me, the key is the "official release" - an official release has been
> > voted on by the relevant PMC and approved for use.  The labeling of it -
> > alpha, beta, etc is moot.  Maybe we should take out that part and instead
> > use:
> >
> > Only release artifacts that have been approved by the relevant PMC may be
> > linked from the download page. All other download links should be removed
> > in a timely fashion.
>
> "All other download links should be removed" - there is no grace period.
>
> The reference to timely removal of links applies to alpha/beta/etc
> releases which are expected to be short-lived.
> They should not remain on the page once the full GA release has been
> published.
>
> However I think it would be better to mostly keep the original
> wording, but tweaked to remove the ambiguity.
>

So how about...


(bullet 4)   - Only release artifacts that have been approved by
the relevant PMC may be linked from the download page.
(bullet 5 - new) - All official pre-releases (e.g. milestones, alphas,
betas) must removed in a timely fashion once the final or GA version has
been released.

It seems to me that the current bullet 4 is blending two problems, or maybe
I'm making it up in my head.

John


>
> > ?
> >
> > On Wed, Dec 7, 2016 at 8:32 PM Niclas Hedhman 
> wrote:
> >
> >> I agree with Stian. It was discussed ~12-14 years ago, how to deal with
> >> "release for public consumption", "release for beta testers", "nightly
> >> builds" and so on. And AFAIR, the Stian's explanation mirrors the
> consensus
> >> from back then, and perhaps the wording is not optimal.
> >>
> >> Niclas
> >>
> >> On Wed, Dec 7, 2016 at 10:31 PM, Stian Soiland-Reyes 
> >> wrote:
> >>
> >> > Hang on, it's perfectly fine for ASF projects to publish and link to
> >> > milestone/alpha/beta releases - as long as they have also gone through
> >> > a formal release VOTE and checking, they are still "official
> >> > releases".
> >> >
> >> > http://www.apache.org/dev/release.html#release-types
> >> >
> >> > What is confusing about your quoted pagraph is that it uses the
> >> > terminology "not full official releases" misleadingly -- but those
> >> > should still be "official releases" - just not at a "stable" or
> >> > "general availability" maturity level.
> >> >
> >> > What is NOT ok is to link from the download page to a non-voted on
> >> > SNAPSHOT build or similar.   That is quite clearly explained in
> >> > http://www.apache.org/dev/release.html - but perhaps not on
> >> > release-download-pages.html.
> >> >
> >> > On 7 December 2016 at 12:31, John D. Ament 
> >> wrote:
> >> > > The following text is found on
> >> > > http://www.apache.org/dev/release-download-pages.html#links (4th
> >> bullet
> >> > in
> >> > > that section)
> >> > >
> >> > > Artifacts which are not full official releases (for example,
> >> milestones,
> >> > > betas and alphas) may be linked from the download page. Links to
> these
> >> > > artifacts should be removed in a timely fashion.
> >> > >
> >> > > I believe it's missing a "not" and should be
> >> > >
> >> > > Artifacts which are not full official releases (for example,
> >> milestones,
> >> > > betas and alphas) may not be linked from the download page. Links to
> >> > these
> >> > > artifacts should be removed in a timely fashion.
> >> >
> >> >
> >> >
> >> > --
> >> > Stian Soiland-Reyes
> >> > http://orcid.org/-0001-9842-9718
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> > For additional commands, e-mail: dev-h...@community.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >> Niclas Hedhman, Software Developer
> >> http://zest.apache.org - New Energy for Java
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Error on Release Download Page page ?

[sebb]

On 8 December 2016 at 01:38, John D. Ament  wrote:
> For me, the key is the "official release" - an official release has been
> voted on by the relevant PMC and approved for use.  The labeling of it -
> alpha, beta, etc is moot.  Maybe we should take out that part and instead
> use:
>
> Only release artifacts that have been approved by the relevant PMC may be
> linked from the download page. All other download links should be removed
> in a timely fashion.

"All other download links should be removed" - there is no grace period.

The reference to timely removal of links applies to alpha/beta/etc
releases which are expected to be short-lived.
They should not remain on the page once the full GA release has been published.

However I think it would be better to mostly keep the original
wording, but tweaked to remove the ambiguity.

> ?
>
> On Wed, Dec 7, 2016 at 8:32 PM Niclas Hedhman  wrote:
>
>> I agree with Stian. It was discussed ~12-14 years ago, how to deal with
>> "release for public consumption", "release for beta testers", "nightly
>> builds" and so on. And AFAIR, the Stian's explanation mirrors the consensus
>> from back then, and perhaps the wording is not optimal.
>>
>> Niclas
>>
>> On Wed, Dec 7, 2016 at 10:31 PM, Stian Soiland-Reyes 
>> wrote:
>>
>> > Hang on, it's perfectly fine for ASF projects to publish and link to
>> > milestone/alpha/beta releases - as long as they have also gone through
>> > a formal release VOTE and checking, they are still "official
>> > releases".
>> >
>> > http://www.apache.org/dev/release.html#release-types
>> >
>> > What is confusing about your quoted pagraph is that it uses the
>> > terminology "not full official releases" misleadingly -- but those
>> > should still be "official releases" - just not at a "stable" or
>> > "general availability" maturity level.
>> >
>> > What is NOT ok is to link from the download page to a non-voted on
>> > SNAPSHOT build or similar.   That is quite clearly explained in
>> > http://www.apache.org/dev/release.html - but perhaps not on
>> > release-download-pages.html.
>> >
>> > On 7 December 2016 at 12:31, John D. Ament 
>> wrote:
>> > > The following text is found on
>> > > http://www.apache.org/dev/release-download-pages.html#links (4th
>> bullet
>> > in
>> > > that section)
>> > >
>> > > Artifacts which are not full official releases (for example,
>> milestones,
>> > > betas and alphas) may be linked from the download page. Links to these
>> > > artifacts should be removed in a timely fashion.
>> > >
>> > > I believe it's missing a "not" and should be
>> > >
>> > > Artifacts which are not full official releases (for example,
>> milestones,
>> > > betas and alphas) may not be linked from the download page. Links to
>> > these
>> > > artifacts should be removed in a timely fashion.
>> >
>> >
>> >
>> > --
>> > Stian Soiland-Reyes
>> > http://orcid.org/-0001-9842-9718
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> > For additional commands, e-mail: dev-h...@community.apache.org
>> >
>> >
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: proposal for a GSoC post-mortem survey

[Niclas Hedhman]

OTOH, surveys is an interesting service, since it doesn't have to be
maintained forever. As long as the output data is committed into source
control, it can be taken down without consequence. Which is radically
different from Wikis, trackers and so on...

Cheers
Niclas

On Wed, Dec 7, 2016 at 10:47 PM, Ulrich Stärk  wrote:

> On 07.12.16 11:32, Daniel Gruno wrote:
> > On 12/07/2016 11:29 AM, Ulrich Stärk wrote:
> >> On 07.12.16 10:26, Bertrand Delacretaz wrote:
> >>> Hi Uli,
> >>>
> >>> On Tue, Dec 6, 2016 at 9:59 AM, Ulrich Stärk  wrote:
>  ...I want to propose a post-mortem survey that
>  hopefully captures a more complete picture
> >>>
> >>> Instead of a survey, how about asking GsoC mentors to send a note here
> >>> about their GSoC success or failure story? We can send them your list
> >>> of questions as a guide, but IMO if we get stories that's more
> >>> powerful.
> >>>
> >>> We can also point them to our private list if they really have
> >>> sensitive stuff to report,
> >>
> >> I saw this as a middle ground between Rich's position of having easy to
> digest data and mine aimed
> >> at getting a as complete as possible picture.
> >>
> >> Also I think that filling out a survey might appeal to more folks than
> writing up a lengthy story.
> >
> > I've been toying with the idea of comdev maybe providing a survey
> > mechanism for the wider ASF for various surveys (instead of relying on
> > 3rd parties, also this would enable proper committer/PMC verification as
> > an option). This would be a great incentive to get started on that idea
> :)
>
> Please don't. Others out there do it much better and more dedicated then
> we can ever do. We might
> discuss getting a corporate account with one of the vendors out there and
> maybe they offer oauth
> integration, but that would require a clear business case.
>
> Cheers,
>
> Uli
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Error on Release Download Page page ?

[John D. Ament]

For me, the key is the "official release" - an official release has been
voted on by the relevant PMC and approved for use.  The labeling of it -
alpha, beta, etc is moot.  Maybe we should take out that part and instead
use:

Only release artifacts that have been approved by the relevant PMC may be
linked from the download page. All other download links should be removed
in a timely fashion.

?

On Wed, Dec 7, 2016 at 8:32 PM Niclas Hedhman  wrote:

> I agree with Stian. It was discussed ~12-14 years ago, how to deal with
> "release for public consumption", "release for beta testers", "nightly
> builds" and so on. And AFAIR, the Stian's explanation mirrors the consensus
> from back then, and perhaps the wording is not optimal.
>
> Niclas
>
> On Wed, Dec 7, 2016 at 10:31 PM, Stian Soiland-Reyes 
> wrote:
>
> > Hang on, it's perfectly fine for ASF projects to publish and link to
> > milestone/alpha/beta releases - as long as they have also gone through
> > a formal release VOTE and checking, they are still "official
> > releases".
> >
> > http://www.apache.org/dev/release.html#release-types
> >
> > What is confusing about your quoted pagraph is that it uses the
> > terminology "not full official releases" misleadingly -- but those
> > should still be "official releases" - just not at a "stable" or
> > "general availability" maturity level.
> >
> > What is NOT ok is to link from the download page to a non-voted on
> > SNAPSHOT build or similar.   That is quite clearly explained in
> > http://www.apache.org/dev/release.html - but perhaps not on
> > release-download-pages.html.
> >
> > On 7 December 2016 at 12:31, John D. Ament 
> wrote:
> > > The following text is found on
> > > http://www.apache.org/dev/release-download-pages.html#links (4th
> bullet
> > in
> > > that section)
> > >
> > > Artifacts which are not full official releases (for example,
> milestones,
> > > betas and alphas) may be linked from the download page. Links to these
> > > artifacts should be removed in a timely fashion.
> > >
> > > I believe it's missing a "not" and should be
> > >
> > > Artifacts which are not full official releases (for example,
> milestones,
> > > betas and alphas) may not be linked from the download page. Links to
> > these
> > > artifacts should be removed in a timely fashion.
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > http://orcid.org/-0001-9842-9718
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>

Re: Error on Release Download Page page ?

[Niclas Hedhman]

I agree with Stian. It was discussed ~12-14 years ago, how to deal with
"release for public consumption", "release for beta testers", "nightly
builds" and so on. And AFAIR, the Stian's explanation mirrors the consensus
from back then, and perhaps the wording is not optimal.

Niclas

On Wed, Dec 7, 2016 at 10:31 PM, Stian Soiland-Reyes 
wrote:

> Hang on, it's perfectly fine for ASF projects to publish and link to
> milestone/alpha/beta releases - as long as they have also gone through
> a formal release VOTE and checking, they are still "official
> releases".
>
> http://www.apache.org/dev/release.html#release-types
>
> What is confusing about your quoted pagraph is that it uses the
> terminology "not full official releases" misleadingly -- but those
> should still be "official releases" - just not at a "stable" or
> "general availability" maturity level.
>
> What is NOT ok is to link from the download page to a non-voted on
> SNAPSHOT build or similar.   That is quite clearly explained in
> http://www.apache.org/dev/release.html - but perhaps not on
> release-download-pages.html.
>
> On 7 December 2016 at 12:31, John D. Ament  wrote:
> > The following text is found on
> > http://www.apache.org/dev/release-download-pages.html#links (4th bullet
> in
> > that section)
> >
> > Artifacts which are not full official releases (for example, milestones,
> > betas and alphas) may be linked from the download page. Links to these
> > artifacts should be removed in a timely fashion.
> >
> > I believe it's missing a "not" and should be
> >
> > Artifacts which are not full official releases (for example, milestones,
> > betas and alphas) may not be linked from the download page. Links to
> these
> > artifacts should be removed in a timely fashion.
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: What's the plan? What are we here for?

[Rich Bowen]

On 12/07/2016 02:42 PM, Peter Hunsberger wrote:
> Now's that's a false dichotomy and you should know better.  Can metrics be
> abused? Sure. Are the people in this group stupid enough to allow that to
> happen?  I highly doubt it.

"This group" is a public mailing list. I don't think stupidity enters
into it.


-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon



signature.asc
Description: OpenPGP digital signature

GSoC: What can we learn from it?

[Daniel Gruno]

I'd like to propose that for GSoC and other such events, we analyze
participation before, after and way after GSoC with the goal of becoming
better at utilizing this event to improve community development, not
only within projects, but also on a broader ASF-wide scale.

If possible, I would love for us to split this into the following sections:

- Pre-participation, for projects:
 - How many projects are involved in GSoC (and over time)
 - How many are aware of it (and are or aren't participating)
 - Why do projects think GSoC is a valuable resource

- Pre-participation, for students:
 - How did you learn about $project
 - What do you know about the ASF
 - What motivated you to apply for GSoC

Post-participation, for projects:
 - Did you feel the dev outcome of GSoC was valuable?
 - ditto, but on a community scale?
 - What could have gone better?
 - What went really well?
 - How can ComDev help next time?

Post-participation, for students:
 - How was your overall experience with GSoC?
 - How was your experience with the project community?
 - Do you feel you know more about the project and the ASF?
 - What could have been handled better?

.then maybe a year later, see if they are still active, and if so,
what they are doing now.

Thoughts? Suggestions?

With regards,
Daniel.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: What's the plan? What are we here for?

[Peter Hunsberger]

Now's that's a false dichotomy and you should know better.  Can metrics be
abused? Sure. Are the people in this group stupid enough to allow that to
happen?  I highly doubt it.

Peter Hunsberger

On Wed, Dec 7, 2016 at 1:01 PM, Ulrich Stärk  wrote:

> On 07.12.16 16:18, Peter Hunsberger wrote:
> >>
> >>
> >>> I guess I'm done talking. I'm going to do some things. Folks can play
> >>> along if they want, but I'm apparently terrible at talking about it. So
> >>> I'll just do.
> >>
> >> Big +1.
> >
> > This thread has been pretty confusing from what I know of "the Apache
> way";
> > if someone wants to do something constructive they should be encouraged
> to
> > do it.  The thought that collecting metrics could somehow harm Comdev is
> > absurd.  People misusing the collected data might be a problem, but
> that's
> > a separate problem that can be addressed one there is some actual data to
> > look at.
> >
>
> Let's try to close pandora's box once we have opened it. Now _that_ is
> absurd.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: What's the plan? What are we here for?

[Daniel Gruno]

On 12/07/2016 08:01 PM, Ulrich Stärk wrote:
> On 07.12.16 16:18, Peter Hunsberger wrote:
>>>
>>>
 I guess I'm done talking. I'm going to do some things. Folks can play
 along if they want, but I'm apparently terrible at talking about it. So
 I'll just do.
>>>
>>> Big +1.
>>
>> This thread has been pretty confusing from what I know of "the Apache way";
>> if someone wants to do something constructive they should be encouraged to
>> do it.  The thought that collecting metrics could somehow harm Comdev is
>> absurd.  People misusing the collected data might be a problem, but that's
>> a separate problem that can be addressed one there is some actual data to
>> look at.
>>
> 
> Let's try to close pandora's box once we have opened it. Now _that_ is absurd.

Unless collecting metrics leads to plague and suffering...I'm not
following the dark rhetoric here. Nothing concrete has been said about
what to do with the data we might collect. Are we afraid that the data
will reflect badly on our initiatives? And if so, why?

If we find that the data we gather is not sufficient or does not show
anything of use, we can simply choose not to act on it until we have
refined out methods, or not at all. But we won't know any of this til we
try.

With regards,
Daniel.

> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: What's the plan? What are we here for?

[Ulrich Stärk]

On 07.12.16 16:18, Peter Hunsberger wrote:
>>
>>
>>> I guess I'm done talking. I'm going to do some things. Folks can play
>>> along if they want, but I'm apparently terrible at talking about it. So
>>> I'll just do.
>>
>> Big +1.
> 
> This thread has been pretty confusing from what I know of "the Apache way";
> if someone wants to do something constructive they should be encouraged to
> do it.  The thought that collecting metrics could somehow harm Comdev is
> absurd.  People misusing the collected data might be a problem, but that's
> a separate problem that can be addressed one there is some actual data to
> look at.
> 

Let's try to close pandora's box once we have opened it. Now _that_ is absurd.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: What's the plan? What are we here for?

[Rich Bowen]

On 12/07/2016 10:18 AM, Peter Hunsberger wrote:
>> >
>>> > > I guess I'm done talking. I'm going to do some things. Folks can play
>>> > > along if they want, but I'm apparently terrible at talking about it. So
>>> > > I'll just do.
>> >
>> > Big +1.
> This thread has been pretty confusing from what I know of "the Apache way";
> if someone wants to do something constructive they should be encouraged to
> do it.  The thought that collecting metrics could somehow harm Comdev is
> absurd.  People misusing the collected data might be a problem, but that's
> a separate problem that can be addressed one there is some actual data to
> look at.
> 

It's not merely a question of encouraging me to go off and do something.
The things that are discussed here are things that will take hundreds of
hours, and thus need broad agreement, and broad volunteer participation.
This is not something that I'm going to go off and do.

This thread is about FAR more than just collecting statistics. It's
about focusing our efforts, and defining what the ComDev PMC is going to
focus attention on in the coming years.

ComDev does a lot of stuff. Some of it doesn't work. Some of it works.
Some of it, we have no idea whether it works, because we haven't defined
what "works" means.

ComDev was formed 10 years ago when a sudden influx of new projects were
starting to significantly change the culture of the ASF, and we wanted
to ensure that we didn't lose, in the process, the core nature of who we
are. There have been a number of concerns expressed in the last few
months that we don't know who we are, as ComDev, and this thread was an
attempt to more clearly define what we, ComDev, are about.

This doesn't mean that you can't work on X or I can't work on Y. It
doesn't mean that everyone must work on Z. It means that we, as ComDev,
have been given a very vague direction by the Board, and that every few
years it's important to make sure that we're doing that, and that we
know who we are.

I fully intend to work on the things that I've enumerated. But I also
have a job, a family, hobbies, and dishes to wash. I want to know that
we, collectively, are walking in the same direction, and that if I, or
two or three of us, or even most of us, need to go do something else for
a year or two, ComDev will continue to walk in that direction without us.

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon



signature.asc
Description: OpenPGP digital signature

Re: What's the plan? What are we here for?

[Peter Hunsberger]

>
>
> > I guess I'm done talking. I'm going to do some things. Folks can play
> > along if they want, but I'm apparently terrible at talking about it. So
> > I'll just do.
>
> Big +1.

This thread has been pretty confusing from what I know of "the Apache way";
if someone wants to do something constructive they should be encouraged to
do it.  The thought that collecting metrics could somehow harm Comdev is
absurd.  People misusing the collected data might be a problem, but that's
a separate problem that can be addressed one there is some actual data to
look at.

Re: proposal for a GSoC post-mortem survey

[Ulrich Stärk]

On 07.12.16 11:32, Daniel Gruno wrote:
> On 12/07/2016 11:29 AM, Ulrich Stärk wrote:
>> On 07.12.16 10:26, Bertrand Delacretaz wrote:
>>> Hi Uli,
>>>
>>> On Tue, Dec 6, 2016 at 9:59 AM, Ulrich Stärk  wrote:
 ...I want to propose a post-mortem survey that
 hopefully captures a more complete picture
>>>
>>> Instead of a survey, how about asking GsoC mentors to send a note here
>>> about their GSoC success or failure story? We can send them your list
>>> of questions as a guide, but IMO if we get stories that's more
>>> powerful.
>>>
>>> We can also point them to our private list if they really have
>>> sensitive stuff to report,
>>
>> I saw this as a middle ground between Rich's position of having easy to 
>> digest data and mine aimed
>> at getting a as complete as possible picture.
>>
>> Also I think that filling out a survey might appeal to more folks than 
>> writing up a lengthy story.
> 
> I've been toying with the idea of comdev maybe providing a survey
> mechanism for the wider ASF for various surveys (instead of relying on
> 3rd parties, also this would enable proper committer/PMC verification as
> an option). This would be a great incentive to get started on that idea :)

Please don't. Others out there do it much better and more dedicated then we can 
ever do. We might
discuss getting a corporate account with one of the vendors out there and maybe 
they offer oauth
integration, but that would require a clear business case.

Cheers,

Uli

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: proposal for a GSoC post-mortem survey

[Rich Bowen]

On 12/07/2016 09:15 AM, Rich Bowen wrote:
> Related (and, I assume, an easy fix for someone that knows the site
> layout better than I) - I discovered that that link, taken from a
> subpage (eg, from
> http://community.apache.org/mentoring/experiences.html) is *relative*
> rather than absolute, and so leads to
> http://community.apache.org/gettingStarted/mentoring/experiences.html
> and 404's. Can someone either fix, or point me to the right file? (Yes,
> I'm sure I'll find it eventually, and fix it myself, but if you beat me
> to it ...)

Fixed. Nothing to see here. :-)

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon



signature.asc
Description: OpenPGP digital signature

Re: Error on Release Download Page page ?

[Stian Soiland-Reyes]

Hang on, it's perfectly fine for ASF projects to publish and link to
milestone/alpha/beta releases - as long as they have also gone through
a formal release VOTE and checking, they are still "official
releases".

http://www.apache.org/dev/release.html#release-types

What is confusing about your quoted pagraph is that it uses the
terminology "not full official releases" misleadingly -- but those
should still be "official releases" - just not at a "stable" or
"general availability" maturity level.

What is NOT ok is to link from the download page to a non-voted on
SNAPSHOT build or similar.   That is quite clearly explained in
http://www.apache.org/dev/release.html - but perhaps not on
release-download-pages.html.

On 7 December 2016 at 12:31, John D. Ament  wrote:
> The following text is found on
> http://www.apache.org/dev/release-download-pages.html#links (4th bullet in
> that section)
>
> Artifacts which are not full official releases (for example, milestones,
> betas and alphas) may be linked from the download page. Links to these
> artifacts should be removed in a timely fashion.
>
> I believe it's missing a "not" and should be
>
> Artifacts which are not full official releases (for example, milestones,
> betas and alphas) may not be linked from the download page. Links to these
> artifacts should be removed in a timely fashion.



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: What's the plan? What are we here for?

[Ulrich Stärk]

Hi Rich

On 05.12.16 18:54, Rich Bowen wrote:
> As has been discussed elsewhere, we don't have a clear idea of what
> we're here for. I believe we need to fix that.

Agreed.

> 
> Why This Matters
> 
> 1) So that we know how to ask for help
> 
> This matters because people *flock* to us saying "I want to help", and
> in pretty much every case our response is "Great! Help! We love you!"
> This is great, but utterly unhelpful.
> 
> Once we have a clear idea of what goals we are working towards, we will
> have a better idea of how to tell people to help us.
> 
> When people come to volunteer to help, we need to know what to tell them
> that they can do, and those things need to come out of an understanding
> of what we're trying to accomplish.
> 
> At the moment, we're doing a number of things. Most of them, we have no
> idea whether they help. I assert that this is primarily because "help"
> is undefined. Help with *what*?
> 
> 2) So that we know whether we're doing it
> 
> Once we define what it is that we are trying to accomplish, we will be
> better able to measure the things that we are doing, to determine in
> some objective way whether they are moving us towards those goals.

As stated before I am no fan of measuring. Let's create transparency first and 
see where we stand
before jumping on an arbitrary metric.

> 
> I realize that "community development" is an endless road. But we should
> at least know which direction we're walking on that road.
> 
> 3) Because we owe the board a report every quarter
> 
> We're supposed to report to the board every quarter telling them how we
> are doing on achieving the goals that they created us to pursue. Except
> that we don't know what those goals are.

The goals as stated in the ComDev resolution [1] are indeed pretty fuzzy 
("responsible for helping
people become involved with Apache projects") and I believe deliberately so. 
ComDev in the past saw
itself as a loose group of people doing "community building stuff" in one way 
or the other.

> 
> So, we engage in various efforts which may or may not do anything. Some,
> like GSoC, are noble, and clearly benefit one audience (the students
> that participate), and *might* benefit projects. Sounds like it does,
> based on the most recent responses on $otherthread. Awesome. But do they
> advance "community development". Hard to say before we define that.
> 

Agreed. If we want to pursue a more active role we first need to decide what 
community development
even means in the context of the ASF.

> 
> So, What's The Plan
> 
> As a full-time community manager, I have a definition of community
> development that appears on my annual performance review. I think it's
> fine for us, as a PMC in the most important open source organization on
> the planet, to have a similar level of rigor.
> 
> Here's some of the things that fall under this header, and which I
> believe should be part of our definition as the ComDev PMC - things that
> we should work towards, and measure every effort against.
> 
> * Increase community diversity. Identify projects that are monocultures
> (or near to them) and help them actively pursue broader community diversity.
> 
> * Develop tools (documentation, training materials, and software tools)
> that projects can use to promote themselves and attract new
> participants. (Participants is a very broad term here, and does not
> refer only to code jockeys.)
> 
> * Educate projects on the Apache Way, so that they can more richly
> experience the organization that they have attached themselves to.
> Identify projects that appear to be operating outside of the Apache Way,
> and gently, kindly, lead them back to the light.
> 
> * Strengthen the bonds between projects and the larger Foundation.
> Defining this is a whole other thread, but means several things to me.
> Identify projects that are satellites and build ties back to the
> "family", in terms of participating in events, participating in
> governance discussions, having adequate membership representation on the
> PMC, and so on.
> 
> * It's not about marketing, but we should be working very closely with
> marketing (press@) to promote what our projects are doing, and promote
> the idea of the ASF as a place where innovation happens, thus drawing in
> an engaged and excited participant community.
> 
> * Internal promotion and cheerleading. Marketing is outward facing.
> Community development is somewhat inward facing. Many of our projects
> have no idea what other projects are doing, and don't care. Doing a
> degree of internal cheerleading, along with the education, is critical
> for building exprit de corps.

All excellent points. I like Alex' categorization into goals, strategies and 
plans and would like us
to focus on goals first. Given Bertrands input should we start writing this up 
in a charter for
discussion?

Cheers,

Uli

[1] 
http://apache.org/foundation/records/minutes/2009/board_minutes_2009_11_01.txt

---

Re: proposal for a GSoC post-mortem survey

[Rich Bowen]

On 12/07/2016 05:29 AM, Ulrich Stärk wrote:
> On 07.12.16 10:26, Bertrand Delacretaz wrote:
>> Hi Uli,
>>
>> On Tue, Dec 6, 2016 at 9:59 AM, Ulrich Stärk  wrote:
>>> ...I want to propose a post-mortem survey that
>>> hopefully captures a more complete picture
>>
>> Instead of a survey, how about asking GsoC mentors to send a note here
>> about their GSoC success or failure story? We can send them your list
>> of questions as a guide, but IMO if we get stories that's more
>> powerful.
>>
>> We can also point them to our private list if they really have
>> sensitive stuff to report,
> 
> I saw this as a middle ground between Rich's position of having easy to 
> digest data and mine aimed
> at getting a as complete as possible picture.
> 
> Also I think that filling out a survey might appeal to more folks than 
> writing up a lengthy story.

+1

A survey is always an awesome first step in identifying the people with
whom you can dig deeper. A question in the direction of "are you willing
to talk more about this" is always a great place to end, and, even in an
anonymous survey, gives an opportunity to get more stories.

Related: Feathercast is always willing to do interviews. Lots of folks
won't write up a user story to save their lives, but will gladly chat
for 10 minutes, which we can then transcribe.

--Rich

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon



signature.asc
Description: OpenPGP digital signature

Re: proposal for a GSoC post-mortem survey

[Rich Bowen]

On 12/07/2016 04:26 AM, Bertrand Delacretaz wrote:
> Hi Uli,
> 
> On Tue, Dec 6, 2016 at 9:59 AM, Ulrich Stärk  wrote:
>> ...I want to propose a post-mortem survey that
>> hopefully captures a more complete picture
> 
> Instead of a survey, how about asking GsoC mentors to send a note here
> about their GSoC success or failure story? We can send them your list
> of questions as a guide, but IMO if we get stories that's more
> powerful.

I note that the GSoC dropdown on http://community.apache.org/ has a link
to "past GSoC experiences" -
http://community.apache.org/mentoring/experiences.html

This would be a good place for those stories. I've already received one
of those stories from Suresh, and am in the process of trying to find
out whether the student in question minds having it posted.

Related (and, I assume, an easy fix for someone that knows the site
layout better than I) - I discovered that that link, taken from a
subpage (eg, from
http://community.apache.org/mentoring/experiences.html) is *relative*
rather than absolute, and so leads to
http://community.apache.org/gettingStarted/mentoring/experiences.html
and 404's. Can someone either fix, or point me to the right file? (Yes,
I'm sure I'll find it eventually, and fix it myself, but if you beat me
to it ...)

--Rich


-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon



signature.asc
Description: OpenPGP digital signature

Re: proposal for a GSoC post-mortem survey

[Shane Curcuru]

Ulrich Stärk wrote on 12/7/16 5:49 AM:
> Thanks for the feedback Shane!
> 
> On 06.12.16 14:09, Shane Curcuru wrote:
>> Ulrich Stärk wrote on 12/6/16 3:59 AM:
...snip...
>> Separately, are we allowed to (by GSoC rules), and would it be
>> practical, to do a short survey for exiting GSoC *students*, or even for
>> last year's students?  Along with capturing some data, it feels like it
>> would be a good way for the ASF to try to maintain a relationship with
>> the student (if they want to; if they ignore us that's fine too).
> 
> Unfortunately it seems like Google decided to take offline all historical 
> data. I cannot access any
> of the past (that includes 2016) student data anymore. All we have is student 
> names from the scoring
> spreadsheets for 2013-2016.

Bummer.  Can we ensure that data about our current GSoC participants
gets put in SVN somewhere for our own historical reference?


...snip...
>>> Should we continue participating in GSoC on a foundation level? (yes/no)
>> Definitely make this one an agreement scale, not boolean.
> 
> What would the scale look like and what would an agreement level of e.g. 3 on 
> a 1-5 scale mean?

Dunno - that's why we have people who write standards for surveys (a
couple of Members have volunteered in the past to help write questions
like this in a standardized way).

https://www.surveygizmo.com/survey-blog/likert-scale-what-is-it-how-to-analyze-it-and-when-to-use-it/

https://www.surveymonkey.com/blog/2014/09/19/2-tips-for-writing-agree-disagree-survey-questions/

For any 'degree' questions, we need to use a standard agree or satisfied
scale that's used in standard surveys.  That likely means the question
needs to be re-phrased so it fits that kind of scale.

- Shane

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Error on Release Download Page page ?

[Shane Curcuru]

John D. Ament wrote on 12/7/16 7:31 AM:
> The following text is found on
> http://www.apache.org/dev/release-download-pages.html#links (4th bullet in
> that section)
> 
> Artifacts which are not full official releases (for example, milestones,
> betas and alphas) may be linked from the download page. Links to these
> artifacts should be removed in a timely fashion.
> 
> I believe it's missing a "not" and should be

+1.  I suggest making the change and cc: legal-discuss@, since legal
should be aware of changes to release policy, even if simple typos like
this.

- Shane

> 
> Artifacts which are not full official releases (for example, milestones,
> betas and alphas) may not be linked from the download page. Links to these
> artifacts should be removed in a timely fashion.
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: What's the plan? What are we here for?

[Pierre Smits]

All I can say is: thumbsup for anyone scratching the itch...

If others feel that the one doing is not doing the right thing, I say: go
scratch...

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Dec 7, 2016 at 1:51 PM, Rich Bowen  wrote:

> On 12/06/2016 04:59 PM, Roman Shaposhnik wrote:
>
> > Now, nothing prevents us from clarifying the charter (or going above and
> beyond
> > it)
>
> That's exactly what I was doing.
>
> It's incredibly frustrating to me how hard it is for anyone at the ASF
> to say "let's make this thing better" without a half dozen people
> hearing "this thing is terribly broken and it's your fault."
>
> I'm suggesting that there are ways that we can be more effective in what
> we're doing. I'm making concrete suggestions of what we can do to be
> more effective in fostering stronger community here at the ASF. I feel
> that this falls well within our charter.
>
> > We have been entrusted by the board to do that community development.
> >
> > Perhaps you'll look at it as semantics -- but my read is that we've been
> > entrusted with *coordination* of said community development. So yes:
> > "we drink and we know things" until such a point that a charter gets
> clarified.
>
> The first job of a PMC is to expand on, and clarify, their charter, and
> determine how they're going to accomplish it.
>
> When this PMC was founded, as was often the case in those days, we all
> just knew what it was that we were supposed to be doing, so we never
> wrote it down. Now, 10 years later, we need to write it down.
>
> This doesn't mean that everything is horribly broken. It means that we
> need to refocus.
>
>
> >> No doubt someone will say that this is the Incubator's job. The
> >> Incubator is there to train projects at onboarding.
> >
> > No way! That's just not the case given the IPMC charter. I really
> strongly
> > disagree with you restricting it that way.
>
> Seriously, Roman? Strongly disagree? Again, what is it with people at
> the ASF getting *offended* all the time. This is likely a discussion for
> another thread, but surely it is the case that one of the Incubator's
> many jobs is to teach projects how to operate within the Apache family?
> How is that "restricting"? It's a statement of one of the Incubator's jobs.
>
> >> We are here to
> >> develop community, and encourage projects to continue doing what the
> >> Incubator taught them, and to draw them deeper into the ASF family. In a
> >> sense ComDev picks up where the Incubator leaves off. And then at some
> >> point we hand off to Attic. It's a circle of life thing.
> >
> > See. That's where my problem with your proposal really begins -- the PMC
> is
> > really either ready or not. If it is ready -- it MUST be capable of
> > self-managing.
> > That includes "training the young'uns" and proliferating ASF culture.
> And if PMC
> > needs resources and/or help -- sure there will be ComDev ready to help.
>
> ... and we are not ready to help. Look at the last dozen threads where
> someone says that they need help, or someone says that they want to
> help. We say a few hand-wavey things and they go away, and we've done
> little or nothing to help.
>
> I'm suggesting some concrete programs we could start to make that more
> helpful, and more scalable. So that it's not just 10 of us sitting
> around drinking and knowing things, but that we have a system whereby
> any project has access to the decades of community intelligence we
> represent here, and our culture is preserved for another generation.
>
> >
> > "Apache Way" governance model is appealing precisely because of the same
> reason
> > that US federal model is: there's a non-negotiable culture statement
> > called Constitution.
> > The rest is left up to the states. And yes Feds can create programs to
> > get state's attention
> > (mostly via financial incentives) but other that that states are free
> > to define their own
> > policies (still within what's allowed by the constitution).
> >
> > But ok, you're clearly increasing the charter of ComDev. That's
> > actually fine as long as the
> > principle of PMC independence I stated above holds.
> >
>
> No, I don't think I'm increasing it. I'm defining what it means, in much
> the same way that the constitution doesn't mean anything all by itself,
> but comes to mean practical things by application, expansion, commentary
> and so on. So, yeah, great analogy.
>
> And we'd kind of suck as a comdev pmc if we violated the constitution. I
> think that goes without saying. I think that you know I'm not advocating
> scrapping the constitution. We've both been here for long enough to
> understand that.
>
>
> > ||| * Increase community diversity. Identify projects that are
> monocultures
> > ||| (or near to them) and help them actively pursue broader community
> diversity.
> >
> > If this is -- "hey, we've noticed your community ca

Re: proposal for a GSoC post-mortem survey

[Jefferson Silva]

Hi community,

I'd suggest to add a few questions to the questionnaire.

- What problems did you face when you ranked and selected among GSoC
applicants? (free text)
- How many (estimate) hours did you take to rank and select among GSoC
applicants?
- How you would classify the relationship created with the student for
developing the project? [Really bad to really good]
- In your opinion, is GSoC effective in making students into contributors?
why/why not? (free text)
- Could you provide us with a representative (typical) story about the
mentoring process? (free text/optional)
- How many hours (estimate) did the mentoring take? (free text)
- How long did the student kept contributing after the end of the program?
[1 month to 12 months]
- After GSoC, how did the student interacted with the community?
  -- proposing new code or functionality
  -- correcting bugs
  -- creating tests
  -- creating documentation

With this information, we can compare the number of hours mentors spend
mentoring, and the code produced by the students, by verifying the
complexity of their code, checking whose code was incorporated etc.

I really would like to help you on this.

I would like to hear your thoughts on this.

Regards,

Jeff

Re: What's the plan? What are we here for?

[Rich Bowen]

On 12/06/2016 04:59 PM, Roman Shaposhnik wrote:

> Now, nothing prevents us from clarifying the charter (or going above and 
> beyond
> it)

That's exactly what I was doing.

It's incredibly frustrating to me how hard it is for anyone at the ASF
to say "let's make this thing better" without a half dozen people
hearing "this thing is terribly broken and it's your fault."

I'm suggesting that there are ways that we can be more effective in what
we're doing. I'm making concrete suggestions of what we can do to be
more effective in fostering stronger community here at the ASF. I feel
that this falls well within our charter.

> We have been entrusted by the board to do that community development.
> 
> Perhaps you'll look at it as semantics -- but my read is that we've been
> entrusted with *coordination* of said community development. So yes:
> "we drink and we know things" until such a point that a charter gets 
> clarified.

The first job of a PMC is to expand on, and clarify, their charter, and
determine how they're going to accomplish it.

When this PMC was founded, as was often the case in those days, we all
just knew what it was that we were supposed to be doing, so we never
wrote it down. Now, 10 years later, we need to write it down.

This doesn't mean that everything is horribly broken. It means that we
need to refocus.


>> No doubt someone will say that this is the Incubator's job. The
>> Incubator is there to train projects at onboarding.
> 
> No way! That's just not the case given the IPMC charter. I really strongly
> disagree with you restricting it that way.

Seriously, Roman? Strongly disagree? Again, what is it with people at
the ASF getting *offended* all the time. This is likely a discussion for
another thread, but surely it is the case that one of the Incubator's
many jobs is to teach projects how to operate within the Apache family?
How is that "restricting"? It's a statement of one of the Incubator's jobs.

>> We are here to
>> develop community, and encourage projects to continue doing what the
>> Incubator taught them, and to draw them deeper into the ASF family. In a
>> sense ComDev picks up where the Incubator leaves off. And then at some
>> point we hand off to Attic. It's a circle of life thing.
> 
> See. That's where my problem with your proposal really begins -- the PMC is
> really either ready or not. If it is ready -- it MUST be capable of
> self-managing.
> That includes "training the young'uns" and proliferating ASF culture. And if 
> PMC
> needs resources and/or help -- sure there will be ComDev ready to help.

... and we are not ready to help. Look at the last dozen threads where
someone says that they need help, or someone says that they want to
help. We say a few hand-wavey things and they go away, and we've done
little or nothing to help.

I'm suggesting some concrete programs we could start to make that more
helpful, and more scalable. So that it's not just 10 of us sitting
around drinking and knowing things, but that we have a system whereby
any project has access to the decades of community intelligence we
represent here, and our culture is preserved for another generation.

> 
> "Apache Way" governance model is appealing precisely because of the same 
> reason
> that US federal model is: there's a non-negotiable culture statement
> called Constitution.
> The rest is left up to the states. And yes Feds can create programs to
> get state's attention
> (mostly via financial incentives) but other that that states are free
> to define their own
> policies (still within what's allowed by the constitution).
> 
> But ok, you're clearly increasing the charter of ComDev. That's
> actually fine as long as the
> principle of PMC independence I stated above holds.
> 

No, I don't think I'm increasing it. I'm defining what it means, in much
the same way that the constitution doesn't mean anything all by itself,
but comes to mean practical things by application, expansion, commentary
and so on. So, yeah, great analogy.

And we'd kind of suck as a comdev pmc if we violated the constitution. I
think that goes without saying. I think that you know I'm not advocating
scrapping the constitution. We've both been here for long enough to
understand that.


> ||| * Increase community diversity. Identify projects that are monocultures
> ||| (or near to them) and help them actively pursue broader community 
> diversity.
> 
> If this is -- "hey, we've noticed your community can benefit from increased
> diversity here are some tools to help with that" -- I'm +1. If this is
> a policing
> function for the board I'm -1 until that time that policing becomes
> part of ComDev
> charter.

Once again, at what point have I said anything about policing? And what
do you know of me that would suggest to you that I'd even *want* to do
any policing, much less build a police force.

Yes, of course I mean help projects to improve.



I see that once again I have communicated poorly. I honestly didn't
think that

Re: Error on Release Download Page page ?

[Pierre Smits]

John,

I believe the 'Links to these artifacts should be removed in a timely
fashion' should be removed as well.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Dec 7, 2016 at 1:31 PM, John D. Ament  wrote:

> The following text is found on
> http://www.apache.org/dev/release-download-pages.html#links (4th bullet in
> that section)
>
> Artifacts which are not full official releases (for example, milestones,
> betas and alphas) may be linked from the download page. Links to these
> artifacts should be removed in a timely fashion.
>
> I believe it's missing a "not" and should be
>
> Artifacts which are not full official releases (for example, milestones,
> betas and alphas) may not be linked from the download page. Links to these
> artifacts should be removed in a timely fashion.
>

Error on Release Download Page page ?

[John D. Ament]

The following text is found on
http://www.apache.org/dev/release-download-pages.html#links (4th bullet in
that section)

Artifacts which are not full official releases (for example, milestones,
betas and alphas) may be linked from the download page. Links to these
artifacts should be removed in a timely fashion.

I believe it's missing a "not" and should be

Artifacts which are not full official releases (for example, milestones,
betas and alphas) may not be linked from the download page. Links to these
artifacts should be removed in a timely fashion.

Re: What's the plan? What are we here for?

[Rich Bowen]

I've got no idea how you read what I wrote and see it as "policing". I used
to think I was a good communicator. I see now I was mistaken.



On Dec 6, 2016 16:59, "Roman Shaposhnik"  wrote:

On Tue, Dec 6, 2016 at 11:45 AM, Rich Bowen  wrote:
>
>
> On 12/06/2016 01:26 PM, Roman Shaposhnik wrote:
>> I'd like to strongly echo Bertrand here. To me, ComDev is first, and
foremost
>> an ASF's braintrust if you will of things that have to do with
>> community development,
>> governance and all around non-coding. It is a place to come and ask
>> for advice, etc.
>>
>> Of course, anything we can do to clean up documentation or provide
>> better guidance
>> is welcome, but I don't think ComDev is responsible for community
>> development of ASF
>> the same way that Rich is responsible for it at his day job.
>
> So, to quote Tyrion Lannister, we drink and we know things?

That's a very, very good way to put it!

> Well, the point of this thread is that I think that's not enough any
> more. It's taking the easy way out, and will eventually lead to an ASF
> where more and more projects are satellites, disconnected from the
> central ASF community, and we no longer share any commonality between
> ASF projects.

Good point, but to answer another point brought by Daniel lets look at
what this PMC's charter says:


   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 coordinating community development
   efforts.


that last part "charged with coordinating community development efforts"
has a very important keyword -- coordinating. We ARE a coordinating body
according to our charter. What it translates into for me is helping
those interested
in community development within each project find common tools, approaches
and techniques. Just like with IPMC -- it is a pull model, rather than
a push one.

Now, nothing prevents us from clarifying the charter (or going above and
beyond
it) but I just wanted to point out where we stand.

> Any community (or company, or country, or whatever) that grows at the
> rate that the ASF is growing risks losing its identity unless culture is
> actively preserved - unless community is actively developed.

I'd argue that establishing initial culture is the job of IPMC (mostly
via mentors).
Monitoring the culture of TLPs is the job of the board and membership.

> We have been entrusted by the board to do that community development.

Perhaps you'll look at it as semantics -- but my read is that we've been
entrusted with *coordination* of said community development. So yes:
"we drink and we know things" until such a point that a charter gets
clarified.

> I want the ASF to still be here in 50 years, and I want the ASF in 50
> years to be something that we would recognize. It's not enough to drink
> and know things - though I recommend both of these things highly. We
> need to be actively training the young'uns to run with our passion when
> we aren't there any more.

Once again - young'uns in terms of the project age is the IPMC's job.
young'uns in terms on n00bs coming to existing ASF projects is individual
PMC's job.

So what's left for ComDev? Policing?

That later point is why I felt compelled to pile on top of Bertrand was
saying.
I really don't want ComDev to become the owners of "The Apache Way".
That's membership's job. Even less do I want ComDev to get in the business
of policing.

> No doubt someone will say that this is the Incubator's job. The
> Incubator is there to train projects at onboarding.

No way! That's just not the case given the IPMC charter. I really strongly
disagree with you restricting it that way.

> We are here to
> develop community, and encourage projects to continue doing what the
> Incubator taught them, and to draw them deeper into the ASF family. In a
> sense ComDev picks up where the Incubator leaves off. And then at some
> point we hand off to Attic. It's a circle of life thing.

See. That's where my problem with your proposal really begins -- the PMC is
really either ready or not. If it is ready -- it MUST be capable of
self-managing.
That includes "training the young'uns" and proliferating ASF culture. And
if PMC
needs resources and/or help -- sure there will be ComDev ready to help.

"Apache Way" governance model is appealing precisely because of the same
reason
that US federal model is: there's a non-negotiable culture statement
called Constitution.
The rest is left up to the states. And yes Feds can create programs to
get state's attention
(mostly via financial incentives) but other that that states are free
to define their own
policies (still within what's allowed by the constitution).

But ok, you're clearly increasing the charter of ComDev. That's
actually fine as long as 

Re: proposal for a GSoC post-mortem survey

[Ulrich Stärk]

Thanks for the feedback Shane!

On 06.12.16 14:09, Shane Curcuru wrote:
> Ulrich Stärk wrote on 12/6/16 3:59 AM:
>> Hi ComDev community,
>>
>> since I believe that measuring two data points only to measure the success 
>> of programs like GSoC in
>> building communities is going to do more harm than good, I want to propose a 
>> post-mortem survey that
>> hopefully captures a more complete picture. Here is my first proposal, let's 
>> discuss.
> 
> This sounds like an excellent addition to our already excellent GSoC
> efforts!
> 
> Separately, are we allowed to (by GSoC rules), and would it be
> practical, to do a short survey for exiting GSoC *students*, or even for
> last year's students?  Along with capturing some data, it feels like it
> would be a good way for the ASF to try to maintain a relationship with
> the student (if they want to; if they ignore us that's fine too).

Unfortunately it seems like Google decided to take offline all historical data. 
I cannot access any
of the past (that includes 2016) student data anymore. All we have is student 
names from the scoring
spreadsheets for 2013-2016.

> 
>>
>> Cheers,
>>
>> Uli
>>
>> *DRAFT*
>>
>> Please specify the name of the student you mentored (free text)
> Why don't we ask for Apache ID?  That way we could do commit analysis if
> we wanted to.

Not all students became committers so not all of the have an Apache ID. We 
could ask that further
down together with the "was the student voted in" question.

> 
>>
>> Do *you* consider GSoC 2016 a success for your project? (yes/no)
>>
>> Why or why not? (free text)
> 
> For several questions: Should we try to capture somewhat structured
> data, instead of boolean/free text?  I'd suggest the "success" use
> Likert scale or some similar degree question instead of boolean.
> 
> "Why or why not?" could be two questions: a "type" and then a free text:
> - Why was this valuable?
> -- Added new module/functionality to your project
> -- Added useful new code to your project
> -- Spurred useful discussion about new code
> -- Added useful documentation, tests, or other things
> -- Created proof of concept that helped move project forward
> ...Or some general areas that might be helpful.

Good push.

> 
>> Do you feel your time spent was worth it? (very high value for time 
>> spent:very low value for time spent)
>>
>> Did the student stick around after GSoC concluded? (yes and still is, yes 
>> briefly, no)
>>
>> Has the student been voted in as a committer or PMC member (yes/no)
>>
>> Does the student's code live on? (as a separate module, as part of the 
>> project's codebase, no, other
>> - please specify)
>>
>> Should we continue participating in GSoC on a foundation level? (yes/no)
> Definitely make this one an agreement scale, not boolean.

What would the scale look like and what would an agreement level of e.g. 3 on a 
1-5 scale mean?

Cheers,

Uli

> 
>>
>> If no, why not?
>>
>> Would you mentor a GSoC student again? (yes, no, under the following 
>> circumstances - please specify)
>>
>> Please specify your Apache ID if you would be willing to discuss your 
>> answers further. (free text)
> 
> Thanks, excellent way to structure the survey.
> 
> - Shane
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: proposal for a GSoC post-mortem survey

[Daniel Gruno]

On 12/07/2016 11:29 AM, Ulrich Stärk wrote:
> On 07.12.16 10:26, Bertrand Delacretaz wrote:
>> Hi Uli,
>>
>> On Tue, Dec 6, 2016 at 9:59 AM, Ulrich Stärk  wrote:
>>> ...I want to propose a post-mortem survey that
>>> hopefully captures a more complete picture
>>
>> Instead of a survey, how about asking GsoC mentors to send a note here
>> about their GSoC success or failure story? We can send them your list
>> of questions as a guide, but IMO if we get stories that's more
>> powerful.
>>
>> We can also point them to our private list if they really have
>> sensitive stuff to report,
> 
> I saw this as a middle ground between Rich's position of having easy to 
> digest data and mine aimed
> at getting a as complete as possible picture.
> 
> Also I think that filling out a survey might appeal to more folks than 
> writing up a lengthy story.

I've been toying with the idea of comdev maybe providing a survey
mechanism for the wider ASF for various surveys (instead of relying on
3rd parties, also this would enable proper committer/PMC verification as
an option). This would be a great incentive to get started on that idea :)

We have a tiny pad where we've been writing down some basic ideas,
https://pad.apache.org/p/survey-ideas - more ideas are welcome!

With regards,
Daniel.

> 
> Cheers,
> 
> Uli
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: proposal for a GSoC post-mortem survey

[Ulrich Stärk]

On 07.12.16 10:26, Bertrand Delacretaz wrote:
> Hi Uli,
> 
> On Tue, Dec 6, 2016 at 9:59 AM, Ulrich Stärk  wrote:
>> ...I want to propose a post-mortem survey that
>> hopefully captures a more complete picture
> 
> Instead of a survey, how about asking GsoC mentors to send a note here
> about their GSoC success or failure story? We can send them your list
> of questions as a guide, but IMO if we get stories that's more
> powerful.
> 
> We can also point them to our private list if they really have
> sensitive stuff to report,

I saw this as a middle ground between Rich's position of having easy to digest 
data and mine aimed
at getting a as complete as possible picture.

Also I think that filling out a survey might appeal to more folks than writing 
up a lengthy story.

Cheers,

Uli

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: proposal for a GSoC post-mortem survey

[Bertrand Delacretaz]

Hi Uli,

On Tue, Dec 6, 2016 at 9:59 AM, Ulrich Stärk  wrote:
> ...I want to propose a post-mortem survey that
> hopefully captures a more complete picture

Instead of a survey, how about asking GsoC mentors to send a note here
about their GSoC success or failure story? We can send them your list
of questions as a guide, but IMO if we get stories that's more
powerful.

We can also point them to our private list if they really have
sensitive stuff to report,

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: What's the plan? What are we here for?

[Bertrand Delacretaz]

Hi,

On Tue, Dec 6, 2016 at 6:30 PM, Alex Harui  wrote:
> ...under these definitions, I think ComDev should certainly have goals

I think your analysis with goals, strategies and plans is spot on,
thanks for that!

Going back to Rich's list I'm fine with comdev having goals like the
following, in (my suggested) order of importance

> 3) Educate projects on the Apache Way...
> 4) Strengthen the bonds between projects and the larger Foundation
> 1) Increase community diversity.
> 6) Internal promotion and cheerleading.

I think strategy and plans don't belong to comdev as a whole, they
belong to sub-groups or individuals who launch specific initiatives
that help reach those goals.

To be concrete, I suggest

a) Working together as comdev to refine our goals using the above as a draft

b) Making progress towards those goals an integral part of our Board
reporting from now on (or 3P: Progress, Problems, Perspectives).

-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org