[DISCUSS] What is a "Blocker" in our JIRA?

[Robert Metzger]

Hi Flink Devs,

while checking our JIRA for the 1.3 release, I found that some issues of
type "New Feature" have the priority "Blocker".
With the time-based release model, I don't think its possible to mark a new
feature as a blocker.

Only a bug that leads to wrong results, system failure or completely
undefined behavior (without any available workaround) is a blocker.
New features, missing documentation or inconveniences are never blockers.

I understand that people want to express that their feature is so important
that it is basically blocking us from creating a release, but with the
time-based release model, this doesn't really apply.

If nobody disagrees, I'll un"block" new features to "Major" new features.


Regards,
Robert


Examples:
https://issues.apache.org/jira/browse/FLINK-6198
https://issues.apache.org/jira/browse/FLINK-6178
https://issues.apache.org/jira/browse/FLINK-6163
https://issues.apache.org/jira/browse/FLINK-6047
https://issues.apache.org/jira/browse/FLINK-5978
https://issues.apache.org/jira/browse/FLINK-5968

[Kostas Kloudas]

Hi Robert,

Thanks for clarifying this so that we all have a common definition of
what is a blocker.

The only thing I would disagree, and only is some cases, is the documentation part.
I think that in some cases, things that have to do with documentation can and
should become blockers. Mainly to motivate devs to take care of them.

There are important parts of Flink which are not (sufficiently or at all) documented
and this can result in confusion / load in the mailing list / wrong user assumptions.

Regards,
Kostas

> On May 4, 2017, at 7:38 PM, Robert Metzger <[hidden email]> wrote:
>
> Hi Flink Devs,
>
> while checking our JIRA for the 1.3 release, I found that some issues of
> type "New Feature" have the priority "Blocker".
> With the time-based release model, I don't think its possible to mark a new
> feature as a blocker.
>
> Only a bug that leads to wrong results, system failure or completely
> undefined behavior (without any available workaround) is a blocker.
> New features, missing documentation or inconveniences are never blockers.
>
> I understand that people want to express that their feature is so important
> that it is basically blocking us from creating a release, but with the
> time-based release model, this doesn't really apply.
>
> If nobody disagrees, I'll un"block" new features to "Major" new features.
>
>
> Regards,
> Robert
>
>
> Examples:
> https://issues.apache.org/jira/browse/FLINK-6198
> https://issues.apache.org/jira/browse/FLINK-6178
> https://issues.apache.org/jira/browse/FLINK-6163
> https://issues.apache.org/jira/browse/FLINK-6047
> https://issues.apache.org/jira/browse/FLINK-5978
> https://issues.apache.org/jira/browse/FLINK-5968

[Ted Yu]

I agree with Kostas.

Considering 1.3 has many new features which need non-trivial effort for
testing, maybe the work on documentation can be done in parallel to testing
RC0.

Cheers

On Thu, May 4, 2017 at 10:54 AM, Kostas Kloudas <[hidden email]
> wrote:

> Hi Robert,
>
> Thanks for clarifying this so that we all have a common definition of
> what is a blocker.
>
> The only thing I would disagree, and only is some cases, is the
> documentation part.
> I think that in some cases, things that have to do with documentation can
> and
> should become blockers. Mainly to motivate devs to take care of them.
>
> There are important parts of Flink which are not (sufficiently or at all)
> documented
> and this can result in confusion / load in the mailing list / wrong user
> assumptions.
>
> Regards,
> Kostas
>
>
> > On May 4, 2017, at 7:38 PM, Robert Metzger <[hidden email]> wrote:
> >
> > Hi Flink Devs,
> >
> > while checking our JIRA for the 1.3 release, I found that some issues of
> > type "New Feature" have the priority "Blocker".
> > With the time-based release model, I don't think its possible to mark a
> new
> > feature as a blocker.
> >
> > Only a bug that leads to wrong results, system failure or completely
> > undefined behavior (without any available workaround) is a blocker.
> > New features, missing documentation or inconveniences are never blockers.
> >
> > I understand that people want to express that their feature is so
> important
> > that it is basically blocking us from creating a release, but with the
> > time-based release model, this doesn't really apply.
> >
> > If nobody disagrees, I'll un"block" new features to "Major" new features.
> >
> >
> > Regards,
> > Robert
> >
> >
> > Examples:
> > https://issues.apache.org/jira/browse/FLINK-6198
> > https://issues.apache.org/jira/browse/FLINK-6178
> > https://issues.apache.org/jira/browse/FLINK-6163
> > https://issues.apache.org/jira/browse/FLINK-6047
> > https://issues.apache.org/jira/browse/FLINK-5978
> > https://issues.apache.org/jira/browse/FLINK-5968
>
>

[Aljoscha Krettek-2]

IMHO, the problem with the “add documentation” issues is that they should ideally have been documented as part of the feature development. (Full disclosure: I’m not innocent there and the Per-Key Window State Doc is somewhat my fault.) Sometimes, though, several features are developed over the course of multiple Jiras and it only makes sense to document the final new state.

Best,
Aljoscha

> On 4. May 2017, at 20:07, Ted Yu <[hidden email]> wrote:
>
> I agree with Kostas.
>
> Considering 1.3 has many new features which need non-trivial effort for
> testing, maybe the work on documentation can be done in parallel to testing
> RC0.
>
> Cheers
>
> On Thu, May 4, 2017 at 10:54 AM, Kostas Kloudas <[hidden email]
>> wrote:
>
>> Hi Robert,
>>
>> Thanks for clarifying this so that we all have a common definition of
>> what is a blocker.
>>
>> The only thing I would disagree, and only is some cases, is the
>> documentation part.
>> I think that in some cases, things that have to do with documentation can
>> and
>> should become blockers. Mainly to motivate devs to take care of them.
>>
>> There are important parts of Flink which are not (sufficiently or at all)
>> documented
>> and this can result in confusion / load in the mailing list / wrong user
>> assumptions.
>>
>> Regards,
>> Kostas
>>
>>
>>> On May 4, 2017, at 7:38 PM, Robert Metzger <[hidden email]> wrote:
>>>
>>> Hi Flink Devs,
>>>
>>> while checking our JIRA for the 1.3 release, I found that some issues of
>>> type "New Feature" have the priority "Blocker".
>>> With the time-based release model, I don't think its possible to mark a
>> new
>>> feature as a blocker.
>>>
>>> Only a bug that leads to wrong results, system failure or completely
>>> undefined behavior (without any available workaround) is a blocker.
>>> New features, missing documentation or inconveniences are never blockers.
>>>
>>> I understand that people want to express that their feature is so
>> important
>>> that it is basically blocking us from creating a release, but with the
>>> time-based release model, this doesn't really apply.
>>>
>>> If nobody disagrees, I'll un"block" new features to "Major" new features.
>>>
>>>
>>> Regards,
>>> Robert
>>>
>>>
>>> Examples:
>>> https://issues.apache.org/jira/browse/FLINK-6198
>>> https://issues.apache.org/jira/browse/FLINK-6178
>>> https://issues.apache.org/jira/browse/FLINK-6163
>>> https://issues.apache.org/jira/browse/FLINK-6047
>>> https://issues.apache.org/jira/browse/FLINK-5978
>>> https://issues.apache.org/jira/browse/FLINK-5968
>>
>>

[Robert Metzger]

I understand the motivation to make documentation equally important as bugs
in software, but from my point of view as a release manager, its not easy
to keep track of the release status when some blockers are not real
blockers (I can't just look at the number in JIRA, but I have to manually
go through the list and read every JIRA to get the real number of release
blockers)

As I've said in my initial email, a blocker is an issue in the code where
no workaround exist and the system is virtually unusable. Missing
documentation is always something users can work around.

I agree with Ted that we can still merge documentation changes while
testing RC0.

On Fri, May 5, 2017 at 7:48 AM, Aljoscha Krettek <[hidden email]>
wrote:

> IMHO, the problem with the “add documentation” issues is that they should
> ideally have been documented as part of the feature development. (Full
> disclosure: I’m not innocent there and the Per-Key Window State Doc is
> somewhat my fault.) Sometimes, though, several features are developed over
> the course of multiple Jiras and it only makes sense to document the final
> new state.
>
> Best,
> Aljoscha
> > On 4. May 2017, at 20:07, Ted Yu <[hidden email]> wrote:
> >
> > I agree with Kostas.
> >
> > Considering 1.3 has many new features which need non-trivial effort for
> > testing, maybe the work on documentation can be done in parallel to
> testing
> > RC0.
> >
> > Cheers
> >
> > On Thu, May 4, 2017 at 10:54 AM, Kostas Kloudas <
> [hidden email]
> >> wrote:
> >
> >> Hi Robert,
> >>
> >> Thanks for clarifying this so that we all have a common definition of
> >> what is a blocker.
> >>
> >> The only thing I would disagree, and only is some cases, is the
> >> documentation part.
> >> I think that in some cases, things that have to do with documentation
> can
> >> and
> >> should become blockers. Mainly to motivate devs to take care of them.
> >>
> >> There are important parts of Flink which are not (sufficiently or at
> all)
> >> documented
> >> and this can result in confusion / load in the mailing list / wrong user
> >> assumptions.
> >>
> >> Regards,
> >> Kostas
> >>
> >>
> >>> On May 4, 2017, at 7:38 PM, Robert Metzger <[hidden email]>
> wrote:
> >>>
> >>> Hi Flink Devs,
> >>>
> >>> while checking our JIRA for the 1.3 release, I found that some issues
> of
> >>> type "New Feature" have the priority "Blocker".
> >>> With the time-based release model, I don't think its possible to mark a
> >> new
> >>> feature as a blocker.
> >>>
> >>> Only a bug that leads to wrong results, system failure or completely
> >>> undefined behavior (without any available workaround) is a blocker.
> >>> New features, missing documentation or inconveniences are never
> blockers.
> >>>
> >>> I understand that people want to express that their feature is so
> >> important
> >>> that it is basically blocking us from creating a release, but with the
> >>> time-based release model, this doesn't really apply.
> >>>
> >>> If nobody disagrees, I'll un"block" new features to "Major" new
> features.
> >>>
> >>>
> >>> Regards,
> >>> Robert
> >>>
> >>>
> >>> Examples:
> >>> https://issues.apache.org/jira/browse/FLINK-6198
> >>> https://issues.apache.org/jira/browse/FLINK-6178
> >>> https://issues.apache.org/jira/browse/FLINK-6163
> >>> https://issues.apache.org/jira/browse/FLINK-6047
> >>> https://issues.apache.org/jira/browse/FLINK-5978
> >>> https://issues.apache.org/jira/browse/FLINK-5968
> >>
> >>
>
>

[Ufuk Celebi-2]

Thanks for this discussion Robert. I agree with your points. +1

Regarding the documentation: I also agree with Kostas and others that
it is very important to have good documentation in place. The good
thing about our current doc deployment model is that we can update the
docs for a released version even after it has been released. Yes,
ideally, we would have the docs already in place when we release and
only do small updates (doc "bug fixes"), but I don't see that
happening in the near future. Therefore, I would unblock the
documentation issues as well for now. Maybe this is a point that we
can revisit in the near future. All in all, I think that the docs have
made tremendous progress in the last 6 months. :-)

– Ufuk

On Fri, May 5, 2017 at 9:47 AM, Robert Metzger <[hidden email]> wrote:

> I understand the motivation to make documentation equally important as bugs
> in software, but from my point of view as a release manager, its not easy
> to keep track of the release status when some blockers are not real
> blockers (I can't just look at the number in JIRA, but I have to manually
> go through the list and read every JIRA to get the real number of release
> blockers)
>
> As I've said in my initial email, a blocker is an issue in the code where
> no workaround exist and the system is virtually unusable. Missing
> documentation is always something users can work around.
>
> I agree with Ted that we can still merge documentation changes while
> testing RC0.
>
> On Fri, May 5, 2017 at 7:48 AM, Aljoscha Krettek <[hidden email]>
> wrote:
>
>> IMHO, the problem with the “add documentation” issues is that they should
>> ideally have been documented as part of the feature development. (Full
>> disclosure: I’m not innocent there and the Per-Key Window State Doc is
>> somewhat my fault.) Sometimes, though, several features are developed over
>> the course of multiple Jiras and it only makes sense to document the final
>> new state.
>>
>> Best,
>> Aljoscha
>> > On 4. May 2017, at 20:07, Ted Yu <[hidden email]> wrote:
>> >
>> > I agree with Kostas.
>> >
>> > Considering 1.3 has many new features which need non-trivial effort for
>> > testing, maybe the work on documentation can be done in parallel to
>> testing
>> > RC0.
>> >
>> > Cheers
>> >
>> > On Thu, May 4, 2017 at 10:54 AM, Kostas Kloudas <
>> [hidden email]
>> >> wrote:
>> >
>> >> Hi Robert,
>> >>
>> >> Thanks for clarifying this so that we all have a common definition of
>> >> what is a blocker.
>> >>
>> >> The only thing I would disagree, and only is some cases, is the
>> >> documentation part.
>> >> I think that in some cases, things that have to do with documentation
>> can
>> >> and
>> >> should become blockers. Mainly to motivate devs to take care of them.
>> >>
>> >> There are important parts of Flink which are not (sufficiently or at
>> all)
>> >> documented
>> >> and this can result in confusion / load in the mailing list / wrong user
>> >> assumptions.
>> >>
>> >> Regards,
>> >> Kostas
>> >>
>> >>
>> >>> On May 4, 2017, at 7:38 PM, Robert Metzger <[hidden email]>
>> wrote:
>> >>>
>> >>> Hi Flink Devs,
>> >>>
>> >>> while checking our JIRA for the 1.3 release, I found that some issues
>> of
>> >>> type "New Feature" have the priority "Blocker".
>> >>> With the time-based release model, I don't think its possible to mark a
>> >> new
>> >>> feature as a blocker.
>> >>>
>> >>> Only a bug that leads to wrong results, system failure or completely
>> >>> undefined behavior (without any available workaround) is a blocker.
>> >>> New features, missing documentation or inconveniences are never
>> blockers.
>> >>>
>> >>> I understand that people want to express that their feature is so
>> >> important
>> >>> that it is basically blocking us from creating a release, but with the
>> >>> time-based release model, this doesn't really apply.
>> >>>
>> >>> If nobody disagrees, I'll un"block" new features to "Major" new
>> features.
>> >>>
>> >>>
>> >>> Regards,
>> >>> Robert
>> >>>
>> >>>
>> >>> Examples:
>> >>> https://issues.apache.org/jira/browse/FLINK-6198
>> >>> https://issues.apache.org/jira/browse/FLINK-6178
>> >>> https://issues.apache.org/jira/browse/FLINK-6163
>> >>> https://issues.apache.org/jira/browse/FLINK-6047
>> >>> https://issues.apache.org/jira/browse/FLINK-5978
>> >>> https://issues.apache.org/jira/browse/FLINK-5968
>> >>
>> >>
>>
>>

[Stefan Richter]

I agree with Robert’s suggestion and also vote for unblocking documentation issues.

> Am 05.05.2017 um 11:06 schrieb Ufuk Celebi <[hidden email]>:
>
> Thanks for this discussion Robert. I agree with your points. +1
>
> Regarding the documentation: I also agree with Kostas and others that
> it is very important to have good documentation in place. The good
> thing about our current doc deployment model is that we can update the
> docs for a released version even after it has been released. Yes,
> ideally, we would have the docs already in place when we release and
> only do small updates (doc "bug fixes"), but I don't see that
> happening in the near future. Therefore, I would unblock the
> documentation issues as well for now. Maybe this is a point that we
> can revisit in the near future. All in all, I think that the docs have
> made tremendous progress in the last 6 months. :-)
>
> – Ufuk
>
> On Fri, May 5, 2017 at 9:47 AM, Robert Metzger <[hidden email]> wrote:
>> I understand the motivation to make documentation equally important as bugs
>> in software, but from my point of view as a release manager, its not easy
>> to keep track of the release status when some blockers are not real
>> blockers (I can't just look at the number in JIRA, but I have to manually
>> go through the list and read every JIRA to get the real number of release
>> blockers)
>>
>> As I've said in my initial email, a blocker is an issue in the code where
>> no workaround exist and the system is virtually unusable. Missing
>> documentation is always something users can work around.
>>
>> I agree with Ted that we can still merge documentation changes while
>> testing RC0.
>>
>> On Fri, May 5, 2017 at 7:48 AM, Aljoscha Krettek <[hidden email]>
>> wrote:
>>
>>> IMHO, the problem with the “add documentation” issues is that they should
>>> ideally have been documented as part of the feature development. (Full
>>> disclosure: I’m not innocent there and the Per-Key Window State Doc is
>>> somewhat my fault.) Sometimes, though, several features are developed over
>>> the course of multiple Jiras and it only makes sense to document the final
>>> new state.
>>>
>>> Best,
>>> Aljoscha
>>>> On 4. May 2017, at 20:07, Ted Yu <[hidden email]> wrote:
>>>>
>>>> I agree with Kostas.
>>>>
>>>> Considering 1.3 has many new features which need non-trivial effort for
>>>> testing, maybe the work on documentation can be done in parallel to
>>> testing
>>>> RC0.
>>>>
>>>> Cheers
>>>>
>>>> On Thu, May 4, 2017 at 10:54 AM, Kostas Kloudas <
>>> [hidden email]
>>>>> wrote:
>>>>
>>>>> Hi Robert,
>>>>>
>>>>> Thanks for clarifying this so that we all have a common definition of
>>>>> what is a blocker.
>>>>>
>>>>> The only thing I would disagree, and only is some cases, is the
>>>>> documentation part.
>>>>> I think that in some cases, things that have to do with documentation
>>> can
>>>>> and
>>>>> should become blockers. Mainly to motivate devs to take care of them.
>>>>>
>>>>> There are important parts of Flink which are not (sufficiently or at
>>> all)
>>>>> documented
>>>>> and this can result in confusion / load in the mailing list / wrong user
>>>>> assumptions.
>>>>>
>>>>> Regards,
>>>>> Kostas
>>>>>
>>>>>
>>>>>> On May 4, 2017, at 7:38 PM, Robert Metzger <[hidden email]>
>>> wrote:
>>>>>>
>>>>>> Hi Flink Devs,
>>>>>>
>>>>>> while checking our JIRA for the 1.3 release, I found that some issues
>>> of
>>>>>> type "New Feature" have the priority "Blocker".
>>>>>> With the time-based release model, I don't think its possible to mark a
>>>>> new
>>>>>> feature as a blocker.
>>>>>>
>>>>>> Only a bug that leads to wrong results, system failure or completely
>>>>>> undefined behavior (without any available workaround) is a blocker.
>>>>>> New features, missing documentation or inconveniences are never
>>> blockers.
>>>>>>
>>>>>> I understand that people want to express that their feature is so
>>>>> important
>>>>>> that it is basically blocking us from creating a release, but with the
>>>>>> time-based release model, this doesn't really apply.
>>>>>>
>>>>>> If nobody disagrees, I'll un"block" new features to "Major" new
>>> features.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> Examples:
>>>>>> https://issues.apache.org/jira/browse/FLINK-6198
>>>>>> https://issues.apache.org/jira/browse/FLINK-6178
>>>>>> https://issues.apache.org/jira/browse/FLINK-6163
>>>>>> https://issues.apache.org/jira/browse/FLINK-6047
>>>>>> https://issues.apache.org/jira/browse/FLINK-5978
>>>>>> https://issues.apache.org/jira/browse/FLINK-5968
>>>>>
>>>>>
>>>
>>>

[Greg Hogan]

+1 to restricting use of “blocker"

-1 to post-hoc documentation and unreleased publication [0]

[0] http://www.apache.org/dev/release-publishing.html

> On May 5, 2017, at 5:06 AM, Ufuk Celebi <[hidden email]> wrote:
>
> Thanks for this discussion Robert. I agree with your points. +1
>
> Regarding the documentation: I also agree with Kostas and others that
> it is very important to have good documentation in place. The good
> thing about our current doc deployment model is that we can update the
> docs for a released version even after it has been released. Yes,
> ideally, we would have the docs already in place when we release and
> only do small updates (doc "bug fixes"), but I don't see that
> happening in the near future. Therefore, I would unblock the
> documentation issues as well for now. Maybe this is a point that we
> can revisit in the near future. All in all, I think that the docs have
> made tremendous progress in the last 6 months. :-)
>
> – Ufuk
>
> On Fri, May 5, 2017 at 9:47 AM, Robert Metzger <[hidden email]> wrote:
>> I understand the motivation to make documentation equally important as bugs
>> in software, but from my point of view as a release manager, its not easy
>> to keep track of the release status when some blockers are not real
>> blockers (I can't just look at the number in JIRA, but I have to manually
>> go through the list and read every JIRA to get the real number of release
>> blockers)
>>
>> As I've said in my initial email, a blocker is an issue in the code where
>> no workaround exist and the system is virtually unusable. Missing
>> documentation is always something users can work around.
>>
>> I agree with Ted that we can still merge documentation changes while
>> testing RC0.
>>
>> On Fri, May 5, 2017 at 7:48 AM, Aljoscha Krettek <[hidden email]>
>> wrote:
>>
>>> IMHO, the problem with the “add documentation” issues is that they should
>>> ideally have been documented as part of the feature development. (Full
>>> disclosure: I’m not innocent there and the Per-Key Window State Doc is
>>> somewhat my fault.) Sometimes, though, several features are developed over
>>> the course of multiple Jiras and it only makes sense to document the final
>>> new state.
>>>
>>> Best,
>>> Aljoscha
>>>> On 4. May 2017, at 20:07, Ted Yu <[hidden email]> wrote:
>>>>
>>>> I agree with Kostas.
>>>>
>>>> Considering 1.3 has many new features which need non-trivial effort for
>>>> testing, maybe the work on documentation can be done in parallel to
>>> testing
>>>> RC0.
>>>>
>>>> Cheers
>>>>
>>>> On Thu, May 4, 2017 at 10:54 AM, Kostas Kloudas <
>>> [hidden email]
>>>>> wrote:
>>>>
>>>>> Hi Robert,
>>>>>
>>>>> Thanks for clarifying this so that we all have a common definition of
>>>>> what is a blocker.
>>>>>
>>>>> The only thing I would disagree, and only is some cases, is the
>>>>> documentation part.
>>>>> I think that in some cases, things that have to do with documentation
>>> can
>>>>> and
>>>>> should become blockers. Mainly to motivate devs to take care of them.
>>>>>
>>>>> There are important parts of Flink which are not (sufficiently or at
>>> all)
>>>>> documented
>>>>> and this can result in confusion / load in the mailing list / wrong user
>>>>> assumptions.
>>>>>
>>>>> Regards,
>>>>> Kostas
>>>>>
>>>>>
>>>>>> On May 4, 2017, at 7:38 PM, Robert Metzger <[hidden email]>
>>> wrote:
>>>>>>
>>>>>> Hi Flink Devs,
>>>>>>
>>>>>> while checking our JIRA for the 1.3 release, I found that some issues
>>> of
>>>>>> type "New Feature" have the priority "Blocker".
>>>>>> With the time-based release model, I don't think its possible to mark a
>>>>> new
>>>>>> feature as a blocker.
>>>>>>
>>>>>> Only a bug that leads to wrong results, system failure or completely
>>>>>> undefined behavior (without any available workaround) is a blocker.
>>>>>> New features, missing documentation or inconveniences are never
>>> blockers.
>>>>>>
>>>>>> I understand that people want to express that their feature is so
>>>>> important
>>>>>> that it is basically blocking us from creating a release, but with the
>>>>>> time-based release model, this doesn't really apply.
>>>>>>
>>>>>> If nobody disagrees, I'll un"block" new features to "Major" new
>>> features.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> Examples:
>>>>>> https://issues.apache.org/jira/browse/FLINK-6198
>>>>>> https://issues.apache.org/jira/browse/FLINK-6178
>>>>>> https://issues.apache.org/jira/browse/FLINK-6163
>>>>>> https://issues.apache.org/jira/browse/FLINK-6047
>>>>>> https://issues.apache.org/jira/browse/FLINK-5978
>>>>>> https://issues.apache.org/jira/browse/FLINK-5968
>>>>>
>>>>>
>>>
>>>

[Ufuk Celebi-2]

On Fri, May 5, 2017 at 2:24 PM, Greg Hogan <[hidden email]> wrote:
> -1 to post-hoc documentation and unreleased publication [0]

Could you quickly confirm that I understand this correctly:
- Post-hoc documentation means not documenting features separately
from their initial PRs?
- Unreleased publication means *not* serving the snapshot docs?

– Ufuk

[Greg Hogan]

My reference to post-hoc was in regards to release. Concurrent dev and doc is of course ideal but I think anyone running snapshot is aware that docs may be somewhat out of sync.

A better link discussing unreleased publication: http://www.apache.org/legal/release-policy.html#publication

Our “How to Contribute” works well to filter “developers” but we do link to the GitHub repo from the left panel.

> On May 5, 2017, at 9:13 AM, Ufuk Celebi <[hidden email]> wrote:
>
> On Fri, May 5, 2017 at 2:24 PM, Greg Hogan <[hidden email]> wrote:
>> -1 to post-hoc documentation and unreleased publication [0]
>
> Could you quickly confirm that I understand this correctly:
> - Post-hoc documentation means not documenting features separately
> from their initial PRs?
> - Unreleased publication means *not* serving the snapshot docs?
>
> – Ufuk