Godot-proposals: Integrate Q&A functionality to the Godot editor

Created on 18 Mar 2020  Â·  6Comments  Â·  Source: godotengine/godot-proposals

Related:

  • godotengine/godot#23043 (re-written as a proposal)
  • godotengine/godot#23395 (a stop-gap PR that won't be merged until changes to RichTextLabel are made)

Describe the project you are working on:

  • Answering questions on social media
  • Learning how to use different parts of the engine API and needing to look up information, tutorials, etc.

Describe the problem or limitation you are having in your project:
This topic has been discussed previously on other social media platforms, but...

There are many different places one can search through for information. Not all sources support organized collections of conversations. Not all places create indexed records of these conversations. There is no go-to place that all users prefer to ask questions at.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Instead of leaving things in this fragmented state and expecting users to do their own due diligence by searching for information on a huge variety of sources (docs, YouTube, Q&A site, Forums, Discord, Reddit, Facebook, etc.), why not emphasize a prescribed place to collect and organize all questions?

Presumably, this would be the Q&A site, but we all know that 1) not everyone even knows it exists, and 2) those who do don't necessarily visit it regularly to browse and ask/answer questions.

This discoverability/accessibility issue could be resolved by creating an interface for such asking and browsing for such questions directly inside the Godot Editor. That way...

  1. The official documentation can direct people's attention to it when they first learn about the engine.
  2. It could have better visibility as a main-screen tab in the Editor beside the AssetLib tab.
  3. Interacting with questions from the community is but a click or hotkey away.
  4. With visibility and accessibility ramped up so much, people on social media platforms are much more likely to congregate information in a single place, just as we try to do for the official documentation.

I am aware that some people are concerned about the idea of having Godot users require a login to use the engine. However, I am not suggesting that any such practice be implemented. People should be able to fetch, cache, and browse questions without requiring a login. Only asking/answering/rating questions should require a login. And even then, it is no different from the behavior that will exist in the Asset Library if we likewise improve usability in that tab and enable people to directly upload and customize assets from the Godot Editor, as suggested in other popular proposals.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

I see 2 main ways of doing this...

Simplest and most direct route:
Create a PHP module for the Q2A tool that Godot uses. In the module, define a web API that the Godot Editor could interact with to remotely execute all website features that are relevant.

  • Pro: it relies on long-standing FOSS technology (Q2A).
  • Pro: it relies on existing tools and features (we already have a Q2A website).
  • Con: we'd have to write PHP code in an aging API (The Q2A API uses legacy PHP idioms).

More difficult, but potentially longer-lasting route:
There are already a large number of refactorings happening for the Asset Library. Why not repurpose part of that codebase to build a nearly identical framework for a Q&A system that runs off of our own PHP Laravel Web API and port the Q&A system to run off the same underlying system as the Asset Library?

  • Pro: shared user login between Asset Library and Q&A. Becomes more like a centralized Godot Hub.
  • Pro: uses more modern PHP standards since all code is then focused in PHP Laravel.
  • Con: Considerably more development work in comparison (not only a Web API layer, but also database, data access, models, views, styling, etc.).

And, of course, whatever we choose for the backend, we will also need to develop an Editor frontend (likely a new main screen tab) that can...

  • display questions and their ratings.
  • open more information about a given question to display answers, their ratings, and their associated comments.
  • submit questions.
  • view your questions and/or questions you've favorited.
  • display the points associated with your user for answering questions (optional).

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It would be used extremely often by tens of thousands of developers, and it would involve far more than a few lines of script to implement. Not to mention the need for backend revisions that are unrelated to the engine source code as well.

Is there a reason why this should be core and not an add-on in the asset library?:
One of the main issues is discoverability and access to the Q&A system that Godot uses. Implementing these features as a third-party addon which, again, users would have to discover and access defeats the entire purpose.

editor

Most helpful comment

Since Question2Answer is barely maintained these days, I'm not sure if this is a good idea in the long run. I kind of fear having to work with its API (if there's any) :slightly_smiling_face:

Also, I'd be wary of the inner-platform effect. If we're not careful, we could end up with Godot reading emails somehow… :eyes:

All 6 comments

See also godotengine/godot-proposals#481.

TBH, I don't like the sound of a forum embedded inside the editor. I find websites much more suitable for something like this, as you can find it from search engines and have a better UI.

@Jummit

I find websites much more suitable for something like this, as you can find it from search engines

If it were embedded inside the editor, then you wouldn't need a search engine in the first place as it's right there in the editor. What's more, a search engine turns up multiple sites, because of which users experience a variety of problems:

  • Users might not know which places are frequented most by other users.

    • There is no ongoing tracker that identifies the most popular official community (nor really should there be as it isn't strictly relevant outside of this topic).

  • Users might not know which places might have the information they want.

    • Information is too fragmented for users to know which platforms are ideal to search through to find the information pertinent to them. They have to waste time searching multiple Q&A platforms (or social media used as a Q&A platform) rather than only searching a single centralized place for such things.

and have a better UI.

This is subjective, but even so, whether or not one platform has a better user interface than another is immaterial if we concentrate work on the Godot Editor itself. After all, we are in full control of the way the Godot Editor is designed. Ergo, if we find any deficiencies in the UI, we can change it for the better.

I'm more concerned with the long-term enhancement of the community's efforts and interactions. If there are problems in the short-term with making the experience more user-friendly, then I'm sure we can easily enough resolve them with a few iterations. I believe the important factor is redirecting as many users as possible to a single centralized source of data.

I really do prefer the built-in docs over the online docs due to efficiency and speed, this was (and is) especially important for me when I first started using Godot as a beginner. Even more efficient when I accidentally figured out a way to instantly lookup classes/methods documentation with Ctrl + LMB on hover.

Since Question2Answer is barely maintained these days, I'm not sure if this is a good idea in the long run. I kind of fear having to work with its API (if there's any) :slightly_smiling_face:

Also, I'd be wary of the inner-platform effect. If we're not careful, we could end up with Godot reading emails somehow… :eyes:

@Calinou

I kind of fear having to work with its API (if there's any)

When I investigated the modules they make available to users, I didn't see anything related to adding a web API to it, so I'm guessing we would need to write one ourselves if we chose to go that route.

Since Question2Answer is barely maintained these days, I'm not sure if this is a good idea in the long run.

This is why I also suggested the more involved, but I believe better long-term plan to repurpose the refactoring work in the Godot Asset Library to also create a Q&A system there. Many of the aspects of an asset in the new GAL are quite similar to Q2A's feature offerings. An Asset/Question has...

  • a dedicated web page
  • a creator
  • a rating voted on by other users
  • people who comment on the web page
  • the ability to be read from a web API
  • (potentially) actual Godot assets attached to the web page (such as scripts, scenes, resource files, etc.).

All you have to do is enable users to 1) comment on comments, 2) pick a single comment as the "right" answer, 3) use a web API to submit a question/answer/comment or update a vote. Then you just make a separate "site" for the Q&A system that runs off a similar API as the GAL. I don't recommend having them run off the same things literally, but you'd get plenty of code reuse out of it and achieve a lot in the long run.

Also, I'd be wary of the inner-platform effect. If we're not careful, we could end up with Godot reading emails somehow…

I definitely understand concerns about this being a kind of slippery slope towards exploding the Godot Editor's feature creep. However, I don't see any reason for these features to get out of hand. It's no more functionality than we will already be doing with the GAL as its refactoring work is done. You simply duplicate most of that code, make a few changes here and there, and duplicate and tweak the existing GAL tab in the editor. It shouldn't be much more complicated than that.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Torguen picture Torguen  Â·  3Comments

SleepProgger picture SleepProgger  Â·  3Comments

SpyrexDE picture SpyrexDE  Â·  3Comments

Dorifor picture Dorifor  Â·  3Comments

PLyczkowski picture PLyczkowski  Â·  3Comments