Hi everyone, Last week was very exciting with the launch of our beloved JanusGraph project. I believe some of you are working hard to get the first build out for JanusGraph. Please shout out if you

This is a great suggestion, well said. There is already some requirements/requests from the user list :-)

Let's migrate them to the GitHub issue list on the repository, so we can keep them organised and execute on them! Let me know of any suggestions to the initiative! Cheers,

Hi everyone, Susan and I are planning to organise a JanusGraph meetup in NYC, around 28th of February. We think it would be a very good idea for teams from our contributors to present the work that

Date have been changed to Wednesday, 1st of March 2017.

Hello, I'd like to hear what folks think about development process for JanusGraph. I think it would be helpful if we had some basic guidelines documented. I'll throw a few ideas out to get the

Excellent idea Haikal, I will have to see if I can make it but I do hope to see you there. Assuming that the entities involved consent, this would be a great opportunity to start publishing relevant

Hi Dylan, The date is flexible if any major roadblock occurs, or majority of people could make it a different day. Looking forward to meeting you there, Dylan! Cheers,

Hi Ted, Thanks for getting this discussion started - I personally like the idea of following the TinkerPop/Apache Way for accepting/rejecting changes, but I'm not familiar with alternatives so I'm

I like the idea of having a formal 'development process' or 'developer' document for the project. Regarding the process to follow to pull in large features, or regular patches or pull request, I am

+1 on design docs for major feature changes. It will help retain the underlying goals and decisions, which will be important as new people join and others roll off. Kafka also requires them

Both JIRA and YouTrack have free-for-open-source licensing options we could apply for (linked). Haikal has mentioned on another thread https://waffle.io as a nice value-add to github issue

So I've been toying with this idea for a while, but I want to make it concrete here so we can shoot it down, mutate, or build it up as needed: I think that we should on-board an additional backend for

A couple of points to consider: +1 policy for commits: A lot of Apache projects have guidelines for how long a pull request must be open before it can be merged. Guidelines typically range from

Should also have linked to the thread on the gremlin-users list - here you go: https://groups.google.com/forum/#!topic/gremlin-users/GNFgkaKjnFc

I’d lean toward keeping it simple and starting out with GitHub issues, especially since the community is still small. If we outgrow or discover difficulty with GitHub, we can always change

I would recommend stick with Github issues for now until we find it is not enough for us to track changes and enhancement requests. Keep it simple.

So it is (quite obviously and plainly stated at the bottom of every comment box, so I'm sorry for asking) possible to attach design docs to github issues. Doh. Also, if we do ever want to migrate to

Great input, thanks everyone. I think we're all pretty much on the same page. If you guys are okay with it, I'll put together a PR to add some candidate documentation around our policies. I'll hit

Great write-up Dylan. I'm not familiar with Apache Ignite beyond name recognition so I'll be doing some more reading. Here's a few thoughts that popped into my head. * Transactions - what concurrency