+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
