Git hub issues should not be ignored

Report a Dgraph Bug

Issues · dgraph-io/dgraph · GitHub shows issues reported in github which are closed just because people use github for reporting. These issues seem to not have been fixed so they shouldn’t be closed.

IMHO It would be better to not use discuss for issues at all.

Hey @WolfgangFahl, I understand your concern but there are many issues on discuss which are more than just trivial bugs, So in order to have a better discussion and community engagement we have decided to port them to discuss and just use discuss for any kind of issue/query/discussion.
Regarding the issues which have not been fixed yet, these are not entirely ignored by us. You can engage on discuss on the associated topic to each issue, whose link is provided in the issue itself.
Feel free to create any new issue on discuss. I am sure the immediate response from our team will change you perception. :slightly_smiling_face:

3 Likes

@minhaj Thank you for getting back to this. my experience of the last week was not so good. It’s awkward to use discuss and i i found two many inconsistencies which are based on ad-hoc decisions like “let’s move to discuss” without thinking about the followup-problems created. The user experience from my point of view at this point is horrible due to inconsistencies on “every corner”. If you stick to github you’ll IMHO more quickly return to a consistent state and not loose people from communities that like github better than discuss. The same hold true for stackoverflow which is much neglected from my point of view by the dgraph team. See e.g. dgraph - How to delete all nodes with a given type? - Stack Overflow

@WolfgangFahl I am sorry if the process has not been so clear:

  • All new issues should go to Discourse not Github
  • All unresolved Github issues (with status/accepted) tag have been ported to Discourse.
  • Our goal is to answer issues in Discourse as fast as we can.
  • Issues that are not solved right away but we think that we should work on them will be tagged as status:accepted (please keep in mind that we are still getting used to this process so I am aware that there are still some important unresolved issues without status:accepted)
  • Accepted issues go to our internal backlog and we work on them based on the priority.

Lastly I will start monitoring the issue category more closely.

1 Like

@WolfgangFahl You would be surprised how quick the Dgraph team responds to threads, if you posted it here on Discuss. I felt the same way at first, and was hesitant to switch over to Discuss, but I was pleasantly surprised about how much more communication, and sharing there is here :slight_smile:

If you’re passionate about learning Dgraph and being apart of the community, it’s worth giving Discuss a try, and you’ll come to find out why it’s so great!

7 Likes

After trying dgraph for a week and not getting it reliably to run i am switching to Apache Jena for the time being. Dgraph v20.07.0 / v20.03.0 unreliability in Mac OS environment is not resolved and is a show stopper for me - it makes my travis CI tests fail randomly so i have to switch dgraph off in that environment.

The learning curve was very frustrating in this week due to all the inconsistencies in your documentation and code. I could not get simple and basic things to work like backup/restore - loading of data - exporting data, queries with group by and so on. Most steps were unpleasant since e.g. there is not much going on in stackoverflow regarding dgraph. Please support gremlin, SPARQL or any other standard way of doing things and life will be much easier for people coming from classical environments. I doubt that it’s worthwhile to try to be “better” before you can do the base things. See Kano_model why not fullfilling basic needs is so frustrating.

Hello @WolfgangFahl. Your issue is something we’re interested in and have been actively exploring. We have had another issue reported on Discuss specifically on Docker Desktop (hyperkit/vpnkit), and found that is was not reproducible on Docker Machine (virtualbox). So we’re curious if this reproduces on Docker Machine. Also, we’re exploring angle with pydgraph client could be an additional factor (or python environment), and so I have a colleague actively looking into this. On TravisCI, this may provide a consistent control to reproduce the issue, but not sure what I can do as far as debugging (traces, profiles, logs) with the dgraph services. So I am looking for a non-Travis way to get to the same results, to see if can get deeper insight as to what is happening.

For documentation, this is something we are both aware and actively working on. I cannot emphasize how vital this is to us. I can definitely relate to the StackExchange point, as I experienced this myself with other projects; this is something I’ll discuss internally. On the topic on a Gremlin, SPARQL, and others (e.g. Cypher), these are not on the immediate roadmap. The current language focus will be around spec GraphQL.

see also What is the default password? · Issue #3680 · dgraph-io/dgraph · GitHub - please go back to github issues - having to enter discuss all the time is really annoying.