> 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-events-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
