-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Galaxy Communication Server #2515
Galaxy Communication Server #2515
Conversation
…mmunication app inside of user-preferences
…communication related options to the user preference panel
Once we accept it in the codebase we have to maintain it or disable/remove it. I am not saying it is impossible, I am merely pointing out/highlighting that by diving into this we are creating a job for future us that is not trivial.
This is fairly hard to believe. I believe you though.:)
(topic: large support overhead) Overall, I think that extending Galaxy with this is of no problem to Main or devteam as long as it is not deployed on Main. Given we do not have a good way how to make this pluggable (other than including it and using config as you have done) the concept is fine. There is a certain nuance in expanding software this way that could be perceived as making it shallow instead of focused, or complex instead of simple. This is notoriously difficult to identify though. |
To start, it is already disabled. It's disabled in like 3 different places :) And sure, we understand. I believe the quote
is somewhat apropos here. (xref). I would counter that this feature would not be under any of the guarantees made by the project (like reproducibility) so if the maintenance burden was much too high in the long term it could be removed. If there are specific maintenance burden concerns maybe we can address those.
99% of their questions are specific to unpublished tools and workflows. It would not be a good experience for them nor others, so I do not encourage them to use it. :( I don't know what the best solution is here.
My experience here is that my PI and users mostly talk to me through text based google hangouts, and never talk to each other. There's no site-specific forum which is what I would love, somewhere my users can exchange knowledge without me being the intermediary. Much more relevant to small sites. (other GalaxyAdmins please feel free to chime in here!)
Yeah, I am not sure what the user experience would be like of this being integrated into main, but I have to side with you that it might be unpleasant and just adding noise. With that said, I'm going to be optimistic here, irc.freenode.net#bioinformatics is quite active. If there are so many people using main, then maybe a community chat could flourish there as well. No, no, no. You see, we're on our way to the world's best, general purpose bioinformatics operating system, Galaxy OS. Just as emacs is a great OS lacking an editor, so is Galaxy! ;) Our users can watch videos, run software, (now) chat, and with docker-compose support we could have a VNC server GIE that lets you browse the internet. Everything you could ever want. Hmm... given that I'm cult of vi, maybe it's time to start the lean, mean vim alternative... ;) long story short, I agree. In a perfect world (to me, speaking as a deployer and admin) Galaxy would be perfectly modular and I would say "right, my focus is on X, Y, and Z and I want to provide additional services A, B, and C to my community" and then be able to choose to install only the components that I need. Possibly unfortunately, we are nowhere near that. We have all or nothing, and the nothing brings extra overhead for those who do want a feature that we believe is appropriate and useful to the vast majority of Galaxy instances, i.e. medium sized ones. |
I think the point is: Does this add enough value to our users to allow it into Galaxy? Does irc #galaxyproject add enough value to galaxy admins / tech users? Do our users currently need more features or more guidance? @jennaj could jump into the discussion and share her thoughts about it. Could this help you in your daily main support? I believe it could also be a pre-room to Biostar redirection. If a question is already answered on Biostar, this could help redirect people (we could even think about a bot looking for keywords in questions and propose Biostar links...but in a |
I would argue for neither - they need more stability, reliability, and discoverability.
Imo this would be at least one person's full-time job just to answer chats on Main. We do not have that person. (also if you don't mind let's continue the discussion about chat on Main somewhere else - maybe even a new issue - so this thread is clean)
Here you are designing functionality that is way more complex than what is proposed here. This problem is even globally unsolved (e.g. SO). We have questions on Biostars that have been asked dozens of times - if we want to implement this we should start there. (but we are getting off topic here:)) If it is simple and useful to a subset of deployers(as it seems now) I am in favor of this, but one of my biggest concerns is scope bloating. |
Just my 2 eurocents here, but I would love to see this available in one way or another. Our users also don't know about biostars and mainly contact me via mail or chat with questions. Often these are also questions about site-specific things (e.g. the data in our shared libraries, custom tools made specifically for their group, or what were the setting to upload via FTP again? etc) that could not be answered on biostars even if they did know about it. I would also love to be able to make a chatroom for a course where the participants can help each other out and discuss the materials, also after the course has ended, and keep their momentum going. I feel they are often quite enthusiastic after a course, but then get stuck when they try using it on their own and are perhaps hesitant to 'bother' me with questions and sort of lose interest/confidence I can understand the concerns for big servers like main, but for smaller ones like ours, where users all know each other, but are spread over different floors/buildings and thus not really talking to each other, I think this could definitely help facilitate communication (and hopefully bypassing me for a lot of it ;P). don't know the best way to handle this code but I'm definitely excited about the potential here and can't wait to try this out :) |
I think my opinion is pretty much the same as @shiltemann's, and I have even heard this suggestion from users before ... I think that the support questions about custom tools (or 'hey, why is my job grey for so long ?') probably applies to whole lot of smaller servers out there. |
Those are very valuable insights, thank you @shiltemann @mvdbeek ! |
Thanks for this discussion, this is why we labelled it RFC.
We explicitly disabled this feature by default and "hide" it under
Then let's improve it. Not sure if you tried it to call it raw, but some specific points would be nice on which we can improve.
As pointed out in the PR description: This is not a duplicate of Biostar. Biostar serves a different use-case and is not-real-time. I see this feature as instant help for users, from users. I actually have no ambitions to join this chat to answer questions.
For me this means we failed (until now) to get people help each other. Also this does not scale and needs to be changed. And hopefully this PR will help.
This is not what this PR is about. I don't think we (as Galaxy-Admins, Committers) should, or could answer questions this fast. But maybe users can. We have many users staying on our Website and waiting, trying tools, reading help pages. All this power is lost currently. These people can help other people if we empower them to do so. Actually, we had the idea to display some text/link inside the chat-window to state that for more elaborated questions biostars is a better place, but here comes the next problem. Biostars is very specific to one domain, at least until know. We see many very specialised Galaxy instances, including Cheminformatics and Language-Processing. Biostars is not known to these users and yet we want to support them or at least give them tools to support each other.
Simply: I want that biologist A helps pharmacologist B as easy as possible as concrete as possible - and more importantly without the middleman - me. A completely different aspect is that people are shy. They do not like to post questions on a forum that stays forever. I see this more the default than the exception. With this feature we give them a more encapsulated environment - for small questions.
Yes and we tried our best to do so, given the current Galaxy code. Maybe we can create an extra folder under scripts, called I completely agree that we need to be very careful of adding too much to Galaxy that is too specific or needs too much maintenance, but we should discuss this as a community and not judging from a usegalaxy.org standpoint. So thanks again to you all for this discussion! (As a side note: I hope that with these small encapsulated projects, we can attract more JS developers to the project and I'm glad @anuprulez took this opportunity to learn the client side of Galaxy) |
This discussion and analysis have been instrumental to me (and possibly to all new to the Galaxy) to recognize the crucial pointers where a new feature could impact an entire application and its users. Once I had read in a blog that in Google, a problem is worthy enough if it has a potential to affect 1 billion people. Along these lines, if a feature is able to cut down the time users take to solve their respective problems, it should be great to adopt it in one way or the other. But at the same time, the incurring cost in terms of man hours to maintain the feature should be kept under check. Thanks a lot for imparting your views especially @bgruening @erasche @remimarenco :) :) |
@@ -1719,3 +1719,23 @@ div.toolTitleNoSection | |||
#for_bears { | |||
display: none; | |||
} | |||
|
|||
// communication channel bootstrap modal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should move this as well into the plugin directory or at least make it communication independent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bgruening Can we create a separate folder in the config/plugins directory for the communication channel codebase and move files like generic-nav-view.js and the communication folder?
For this +// communication channel bootstrap modal
we can create a new css file and move these styles there. It cannot go within the communication.css file as it loads inside the iframe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please create a new directory in config/plugins
, maybe tabs
or menu
and move all needed files to there.
@erasche @guerler @martenson: Please check the latest code. @anuprulez tried to add a more generalized plugin-mechanism for the masthead, that could hopefully be used by other extensions as well. Not sure how to proceed with the css part. |
Thanks for all the hard work on the @bgruening @anuprulez IMO, for this to truly be a plugin approach, what's needed is a way to avoid touching
I wonder if it'd be possible to reuse some code from the visualization plugin framework to make this happen or if @guerler has a better idea of how to approach this. |
|
👍 |
Thanks @martenson and everyone for review! |
Realtime communication server and its user-interface
Galaxy makes it very easy to analyse data but communicating with other researchers
and sharing tricks or asking questions is too hard and a for many people big hurdle.
We should promote https://biostar.usegalaxy.org wherever we can, but I think there is also a need
for quick, instant help ... like developers use IRC.
This PR integrates a realtime communication server and it's user-interface.
This is how it looks like:
It features a chat-application with a gloabl room where all users can communicate with each other.
To offer more specilised rooms for bigger Galaxy instance we have integrated persistent communication rooms that can be configured
by an admin via
galaxy.ini
. These additional global chat-rooms will stay even if no user is logged in and can bejoined/followed by all interested users. Moreover, we included an option to create personal chat rooms.
These rooms will not be listed to all users.
This is how you can use it:
At first you need to install a few requirements.
. GALAXY_ROOT/.venv/bin/activate
# activate Galaxy's virtualenvpip install flask flask-login flask-socketio eventlet
# install the requirementsAs a next step start the communication server with something like this:
./scripts/communication/communication_server.py --port 7070 --host localhost
Please make sure the host and the port matches the ones in
./config/galaxy.ini
andset the
secret_id
in galaxy.iniWe implemented this as an external implementation as
we were not sure if everyone agrees that such a feature should be deeply integrated into Galaxy.
As a consequence and to protect user-privacy we disabled the communication server and the admin as well as the
user needs to explicitly enable it.
The communication server can be controlled on three different levels:
Credits:
Thanks a lot to Anup Kumar (@anuprulez) a Galaxy first time contributor, Rémi Marenco (@remimarenco) and Eric Rasche (@erasche). It's always a pleasure to work with you guys!
Any comments welcome! What do you think about such a feature, any other way how we should integrate this.
Thanks and see you all at GCC!