Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Opening GitHub Discussion as the community discussion board #3346

Closed
jamieliu1023 opened this issue Nov 23, 2021 · 3 comments
Closed

Comments

@jamieliu1023
Copy link
Contributor

Why GitHub Discussion?

Community members need a place for open technical discussion about the Nebula Graph core.

But why GitHub Discussion you might ask? Why not just use Issues? Quote the introduction to Discussion from the GitHub docs:

"GitHub Discussions is a collaborative communication forum for the community around an open source project. Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project board and are not related to code, unlike GitHub Issues. Discussions enable fluid, open conversation in a public forum."

In a word, Discussion is NOT for issue tracking, it is for open discussion about an idea.

GitHub Discussion vs The existing forum

Currently there is a forum for users to ask questions and get support. However, there is not much going on there. Plus people need to create an account there to participate. GitHub Discussion is a more native way for community members to interact with each other around the project because the code is based there and the discussion can be directly related to an existing issue or PR. For convenience of maintenance, GitHub Discussion is a better choice.

What can be discussed on GitHub Discussion?

This is a hub where you can discuss everything related to the design and implementation of the Nebula Graph project. It serves as a forum for open-ended discussions. For example, if you have an idea about adding a specific feature to Nebula Graph but are not sure how to implement it, then Discussion is the go-to place. If you have a concrete problem or design idea, please file an issue instead.

What about the ecosystem tools around Nebula Graph?

There will be a category named "Ecosystem Tools" in this forum for community members to discuss technical questions around tools such as clients.

The whole point here is to provide a communication channel for open technical discussion in the Nebula Graph community, so that any community member who is interested in anything that is ongoing has the opportunity to join the discussion and contribute his/her thoughts, which is what open source means.

Please feel free to add any comment about:

  1. If GitHub Discussion is the best communication channel
  2. Anything that you think can be discussed here
@wey-gu
Copy link
Contributor

wey-gu commented Nov 24, 2021

Thank you @jamieliu1023 for bringing this to the nebula community.

Indeed, a place to enable open design/ open development on the discussion would be nice:

It's a more focused/ narrow/ discussion-originated place(as a supplement) comparing to PR, RFCs in file, user forum or the closed confluence.

  1. It's obviously more focused on open design/development compared to the user forum
  2. It's narrowing down to the dev/design discussion compared to the PR itself, where more of an implementation perspective is being recorded
  3. It's more discussion-originated on designing new feature/core changes compared to pure RFCs in codebase(in which case, the discussion would be in PR review or corresponding issues, and I think that would work, too)

And, with this thread(on turning on the GH discussion), I would like to emphasize/hands-up again that open design/development would help our design process with higher efficiency in the long-term, although, in the short-term, having discussion offline closed door with a few guys would be fast, that context, trade-offs discussion, decision-making process, not being recorded, will make it hard for any newcomers joining the nebula community, for anyone.

For example, the design documentation(revising history) and discussions only in offline talks or sinking in the confluence comment system will lead unfortunately no one would know how each design evolved to where it is now, even after we copy the design documentation to GitHub after it's settled, which could be referred/learned by anyone who needs to after years when needed if it's recorded(for offline syncing discussion, a summary to be recorded) and opened. This is a good example and it benefits everyone including those who were involved in the close discussion(we all struggled on forgetting why we coded something as it is, or just me?)

Thus the suggested flow could be:

  • Put RFC/Proposal-like topics somewhere in public(in GH Discussion or an Issue with a proper label)
  • Having sync discussions offline when needed, while recording the milestones in the topic
  • Having async discussions in this thread for the topic
  • DO actually maintain RFCs in codebase before or together with the implementation, which is traceable purely relying on codebase(when you were reading code histories) and it could be rendered to dev documentation(like this rendered to this)

Open design/dev looks inefficient in short-term, while I doubt, if we do it in a proper process, as we are having new-comers almost every week, it could potentially even accelerate our development in the first place not to mention it will for sure improve in the long term(for example, referring to a public discussion/RFC itself is somewhat the best commit message/context, which we were complained to be lack of), plus, we make decisions based on long term, right?

Thanks
BR//Wey

@jamieliu1023
Copy link
Contributor Author

Thanks so much for sharing your thoughts on this @wey-gu The proposed flow makes sense to me.

@jamieliu1023
Copy link
Contributor Author

The Discussion board has just been enabled: https://github.com/vesoft-inc/nebula/discussions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants