On Tue, Jul 18, 2017 at 3:25 PM, P. Taylor Goetz <[email protected]> wrote:
> > 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 > > > "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." The website is a bit hard to handle for me. We had two choices: the CMS and the generated code in git we chose. At the time, the ruby based templating engine did not run on my laptop. I also have not had the cycles to learn the system very well. Josh helped out by updating things last release. The website was originally a contribution. That person (sorry I can not remember the name) has not been involved since. We actually discussed this decision at length when bootstrapping the project, but you know what they say about the best layed plans (it is now a small pain point). Without stating the obvious I'm not super keen on the web dev. "The Gossip community should figure out whether it is RTC (Review Then Commit)..." Essentially we are "review then commit". This is because the vast majority of contributions have come from non-committers. I would say I have handled a large portion of them from triage stage, to reviews, to commit. If I seem to be lagging I would not terribly mind if a committer went "review then commit" for some types of work. However, I would be best if people divided time between their commit-then-review initiatives and reviewing other peoples work. 'I would propose rephrasing that to “Features that make Gossip useful” is the goal.' Well just on this entire topic, for the last two release I pitched a roadmap type approach. We took the tickets moved them into 1.1.2, some people engaged and took them on, some of those were finished, some were not, others were added in finished. One of the problems I had with that course of action was there was a ticket in 1.1.2 say for example "refactor xyz" now I had a feature in mind add "abc" that would have had to touch the "xyz" code. I waited ended up waiting and dodging things I wanted to work on. Overall it was not successful. I was waiting around, sometimes for things that fell off someones radar, and all it resulted in was a lot of emails to be inbox as I changed the fix version back and forth! The end goal is for gossip to be in everything, your grid computer platform, your toothbrush etc. We need to prioritize the toothbrush over the grid computing platform or vice versa. But the challenge is when we slot out things we do not have full or part time bodies. Also I personally lose interest in something I thought was cool 10 minutes ago (as do others). We basically get the features people want to work on at that moment.
