How are new features / project directions being discussed?

[Chip Childers <ch...@apache.org>]

Hey all,

I spent a little time combing through the mailing list over the last
couple of days. I think that the Brooklyn community is doing pretty well
as a podling right now, but one thing struck me... and I wanted to ask
about it.

Keep in mind that I'm not familiar enough with the code itself to have
any opinions about it, so my question is really a qualitative one about
community communications and decision making.

When I look at the ML, I see a significant percentage (if not all) of
the technical decisions happening via pull requests. That's great, and
it's a good way to do lower level code reviews. But what struck me is
that I couldn't find any place where the community is collaborating on
feature proposals, where the project wants to go, etc...

Generally, I've seen that this means one of two things (or some
combination thereof):

1 - The project is in a position where only minor work is occurring, and
that's just the state of affairs. Nothing dramatic means no discussions
to be had beyond the code-level reviews in the PRs.

2 - Some planning is happening outside of the project, and the project
itself is only able to see the code contributions that are a result of
that planing.

Now, to be clear, item 2 is expected in some ways... Companies involved
certainly have the right to plan their own areas of focus. No issues
with that.

However, since I said this is really a qualitative comment, the optics
on the mailing list are that there doesn't appear to be a community
planning process. Having a community planning process is something that
can really help to attract people that might not have been contributing
yet. It's also a great way to draw out ML lurkers that have been silent
but are on the lists, so that they have a place to comment and provide
feedback.

To be sure, I don't see this as a *problem*, but more as an observation
that may present an opportunity for Brooklyn to grow it's community.

Thoughts?

-chip

Re: How are new features / project directions being discussed?

[Alex Heneveld <al...@cloudsoftcorp.com>]

+1

I think "going straight to PR" is the biggest issue.

This isn't always the case.  Several technical decisions and feature 
items have come through the list (brooklyn maven plugin, website 
rewrite, tosca support) and sometimes also JIRA.  Not much has been done 
off list -- but a fair amount has been only on IRC, or just in PR's, 
neither of which many people see.

In any case whatever it is, if it's something people might be interested 
in send it to the list.  If not, then it shouldn't be committed unless 
it's trivial.  The logical conclusion then (just in case anyone is rusty 
on their modus tollens) is that all non-trivial commits should be 
discussed on list.

That said I'm as guilty as anyone.  So thanks Chip for the nudge.

The other semi-process we've been using are shared documents for feature 
proposals [1].  These have been announced on the list but I think we 
refine this process so that we email PDF's of the doc to the mailing 
list (a) when it is first proposed and (b) once it is completed; and (c) 
send significant updates/summaries to the list for wider discussion.  
(The reasoning here is that it will be aggravating to have small details 
discussed here, and that a shared doc allows good updating and makes it 
easy to get comments from anyone, but at the same time we want permanent 
records lodged within Apache.)

Best
Alex

[1] 
https://drive.google.com/drive/#folders/0B3XurVLRa7pIc1JwSExJZVQwTG8/0B3XurVLRa7pIMlZQSUxrdTh4Wmc



On 09/01/2015 11:36, Aled Sage wrote:
> Chip,
>
> Very good points.
>
> We definitely fall into category (2): too much planning happening 
> outside of the mailing list. We should remedy that - ensuring big 
> features are proposed + discussed on the list, for all the reasons you 
> give.
>
> I'll make more of an effort to to do that, and would appreciate if 
> others do the same.
>
> ---
> Making a basic roadmap available for the community is also important. 
> Should we set up http://wiki.apache.org/brooklyn, or alternatively 
> just have it as a page on https://brooklyn.incubator.apache.org 
> (though that is slightly harder for the community to edit due to how 
> the website is published).
>
> Aled
>
>
> On 07/01/2015 15:03, Chip Childers wrote:
>> Hey all,
>>
>> I spent a little time combing through the mailing list over the last
>> couple of days. I think that the Brooklyn community is doing pretty well
>> as a podling right now, but one thing struck me... and I wanted to ask
>> about it.
>>
>> Keep in mind that I'm not familiar enough with the code itself to have
>> any opinions about it, so my question is really a qualitative one about
>> community communications and decision making.
>>
>> When I look at the ML, I see a significant percentage (if not all) of
>> the technical decisions happening via pull requests. That's great, and
>> it's a good way to do lower level code reviews. But what struck me is
>> that I couldn't find any place where the community is collaborating on
>> feature proposals, where the project wants to go, etc...
>>
>> Generally, I've seen that this means one of two things (or some
>> combination thereof):
>>
>> 1 - The project is in a position where only minor work is occurring, and
>> that's just the state of affairs. Nothing dramatic means no discussions
>> to be had beyond the code-level reviews in the PRs.
>>
>> 2 - Some planning is happening outside of the project, and the project
>> itself is only able to see the code contributions that are a result of
>> that planing.
>>
>> Now, to be clear, item 2 is expected in some ways... Companies involved
>> certainly have the right to plan their own areas of focus. No issues
>> with that.
>>
>> However, since I said this is really a qualitative comment, the optics
>> on the mailing list are that there doesn't appear to be a community
>> planning process. Having a community planning process is something that
>> can really help to attract people that might not have been contributing
>> yet. It's also a great way to draw out ML lurkers that have been silent
>> but are on the lists, so that they have a place to comment and provide
>> feedback.
>>
>> To be sure, I don't see this as a *problem*, but more as an observation
>> that may present an opportunity for Brooklyn to grow it's community.
>>
>> Thoughts?
>>
>> -chip
>

Re: How are new features / project directions being discussed?

[Aled Sage <al...@gmail.com>]

Chip,

Very good points.

We definitely fall into category (2): too much planning happening 
outside of the mailing list. We should remedy that - ensuring big 
features are proposed + discussed on the list, for all the reasons you give.

I'll make more of an effort to to do that, and would appreciate if 
others do the same.

---
Making a basic roadmap available for the community is also important. 
Should we set up http://wiki.apache.org/brooklyn, or alternatively just 
have it as a page on https://brooklyn.incubator.apache.org (though that 
is slightly harder for the community to edit due to how the website is 
published).

Aled


On 07/01/2015 15:03, Chip Childers wrote:
> Hey all,
>
> I spent a little time combing through the mailing list over the last
> couple of days. I think that the Brooklyn community is doing pretty well
> as a podling right now, but one thing struck me... and I wanted to ask
> about it.
>
> Keep in mind that I'm not familiar enough with the code itself to have
> any opinions about it, so my question is really a qualitative one about
> community communications and decision making.
>
> When I look at the ML, I see a significant percentage (if not all) of
> the technical decisions happening via pull requests. That's great, and
> it's a good way to do lower level code reviews. But what struck me is
> that I couldn't find any place where the community is collaborating on
> feature proposals, where the project wants to go, etc...
>
> Generally, I've seen that this means one of two things (or some
> combination thereof):
>
> 1 - The project is in a position where only minor work is occurring, and
> that's just the state of affairs. Nothing dramatic means no discussions
> to be had beyond the code-level reviews in the PRs.
>
> 2 - Some planning is happening outside of the project, and the project
> itself is only able to see the code contributions that are a result of
> that planing.
>
> Now, to be clear, item 2 is expected in some ways... Companies involved
> certainly have the right to plan their own areas of focus. No issues
> with that.
>
> However, since I said this is really a qualitative comment, the optics
> on the mailing list are that there doesn't appear to be a community
> planning process. Having a community planning process is something that
> can really help to attract people that might not have been contributing
> yet. It's also a great way to draw out ML lurkers that have been silent
> but are on the lists, so that they have a place to comment and provide
> feedback.
>
> To be sure, I don't see this as a *problem*, but more as an observation
> that may present an opportunity for Brooklyn to grow it's community.
>
> Thoughts?
>
> -chip