On Jul 11, 2017, at 11:15 AM, Русак Максим <[email protected]> wrote:
"Features for features" is not our goal. "Features for solving users'
pain" have sense.
I would propose rephrasing that to “Features that make Gossip useful” is
the goal.
On Jul 11, 2017, at 12:58 PM, Edward Capriolo <[email protected]>
wrote:
There is no simple answer. I think the primary vehicle is blogging and
community. For example I asked everyone to write up their GSOC work into
blogs:
- Wrote a blog regarding Data Change Event Listeners
- https://medium.com/@mirage20/listening-to-data-change- <
https://medium.com/@mirage20/listening-to-data-change->
events-in-apache-gossip-a0f0a4ea4c21
<https://medium.com/@mirage20/listening-to-data-change-event
s-in-apache-gossip-a0f0a4ea4c21 <https://medium.com/@mirage20/
listening-to-data-change-events-in-apache-gossip-a0f0a4ea4c21>>
- Wrote a blog regarding Data Replication Control
- https://medium.com/@mirage20/data-replication-control-in- <
https://medium.com/@mirage20/data-replication-control-in->
apache-gossip-35777771e2bb
I can tweet out these blogs, some people follow me, they might re-tweet,
word of mouth we get users who try software or committers interested in
scratching their own itch.
+1 I think growing the community should be the primary goal at this point.
But to grow the community people need to know about the project and more
specifically what Gossip can do for them and their projects.
The blog posts you linked to are great, and I will tweet them out as well.
However, they are pretty deep in the weeds. That shouldn’t be taken as a
criticism, I just want to make the point that we should focus more on what
Gossip can be used for. To that end I’d suggest focusing on higher-level
use cases. Build some sample applications (anyone remember the J2EE Pet
Store?) that do something interesting/useful with Gossips features, include
it in the distribution, write a blog post or documentation about it, and
promote it. Being able to get a working sample application running in less
than 15 minutes can be powerful in terms of enticing users to dig deeper.
I also can’t overstate the importance of documentation. When I land on the
Gossip website, I should quickly learn what it is, its features, and what
use cases it is applicable too. Then I should be able to clone the repo and
get some sample apps running with minimal friction. Right now to get to the
current examples I need to dig into the GitHub repo to find the README for
the examples. The examples should be (linked) front and center on the
website/main README. And again, there should be examples that do something
useful.
On Jul 17, 2017, at 5:31 PM, Edward Capriolo <[email protected]>
wrote:
We just do not have the bodies for that. If you want to make a change
(as
a committer) you do not really have to wait around for consensus. For a
committer there is an implicit "WILL MERGE IN 2 DAYS IF NO COMMENT". If
you
are not a committer (or want to wait for my blessing) you are probably
going to have to send me a singing telegram or two. Doing the apache
releases takes cycles, mentoring the GSOC proposals takes cycles, life,
jobs, etc.
The Gossip community should figure out whether it is RTC (Review Then
Commit) or CTR (Commit Then Review) or some hybrid (e.g. RTC for main
codebase, CTR for documentation, etc.). For the “WILL MERGE IN X DAYS” I
would suggest making that explicit in the pull request: e.g. “I plan on
merging this in X days if there are no objections.” That gives other
committers/contributors a heads up about your intent.
As for Gossip having a direction, I don't want Gossip to follow the lead
of
other "owned" apache projects. "Hey we are 'EdTech' the commercial
consulting/solutions arm in the engine room of 'apache gossip' we have
all
the committers and we have a ROAD MAP and our CTO KNOWS WHAT TO DO BASED
ON
WHAT OUR INVESTORS WANT TO HEAR and if your working on something else
......tough crap." :)
+1 Apache projects are owned, led, etc. by their respective communities,
not any individual or outside organization.
I am trying to move at a pace that others can follow/play along. I
_COULD_
have implemented all the CRDTs, but I did one and left the rest open.
This
leaves a door open for others to make meaningful contributions. That is
essentially what I am trying to do, guide.
That’s a good approach. Another one is to mark issues with a “newbie”
label.
If i had more time (job, gossip
(reviews, releases, gsoc), other apache pmc roles, 2 year old) i would
probably do more outreach like meetups and blogs. There are less bodies
on
deck then I expected at this phase but such is life. I see some projects
are in the incubator for 3-4 years, not trying to go that long, but not
trying to rush either.
Outreach is not the responsibility of a single person, but that of the
whole community.
Graduation is largely a function of growing the community and making
releases. That reiterates my point that lowering the bar for entry to new
users is critical.
Code is the easy part, Community is hard but arguably more important.
Luckily there are some fairly simple things that can be done that will go a
long way in terms of growing the community.
-Taylor
