This issue continues the discussion for legacy trac ticket 2097:
jonc125 created the following ticket on 2012-04-26 at 11:15:53, it is owned by jonc125
This (or something like it) was requested at the workshop. One suggestion was to install a stackoverflow style instance for user questions.
This is a child of (trac ticket 1989), which opened up parts of the Chaste Trac system to the public. See in particular comment:8🎫1989, which suggests using OSQA, with LDAP auth in order to share credentials with Trac.
See also http://scicomp.stackexchange.com/ and http://www.biostars.org/.
Comment by mirams on 2015-03-02 at 12:03:32
The Biostars one is specifically for science software, and still in active development https://github.com/ialbert/biostar-central Looks like a good bet to me.
Comment by fcooper8472 on 2017-06-12 at 16:14:37
I have recently investigating this as part of (trac ticket 2904).
I'm against using Biostars:
Biostars looks reasonable, but I have the following thoughts:
- It does not appear to be under active development any longer; only five commits in the last year: GitHub page
- Any system running locally on a machine in Oxford would go against the strategic plan of decentralising Chaste now that the developers are distributed around the world
- It would be another service that someone would have to be responsible for knowing how to fix, upgrade, etc.
For these reasons, I think we should limit the installation of any new tools on the Chaste server, and the integration of anything new with trac.
GitHub instead?
My suggestion, instead, would be to start making greater use of GitHub. Now that we have the releasable code hosted publicly, it would make sense in my mind to migrate (over time) a number of things (topic for another ticket!).
Specifically regarding the mailing list, I think the GitHub issues form a very natural way for us to do what we want:
GitHub issues: how would it work?
Issues are similar to trac tickets. They can be assigned to people and to projects, and have labels and milestones.
Default labels include bug and question. Multiple labels can be applied to an issue. Were we to encourage users to submit issues instead of emailing the list, any of us could assign, for instance, question and component: cell_based labels, and assign the relevant developer per the question subject.
Importantly, no sign-up is necessary to see issues, and a GitHub account is all that is necessary to create a new issue, which would prevent us needing to do any user administration.
Issues are open until they are closed. This would hopefully prevent any questions being forgotten about.
We can provide a direct link to the questions 'section', as opposed to all issues: https://github.com/Chaste/Chaste/labels/question
Next steps
My feeling is that this is an improvement on the mailing list, and does not require setting up anything new.
Are there:
- Any features we would want that this does not offer
- Any other cons to using GitHub issues
- Anyone hugely in favour of sticking with the original plan of something Biostars-esque?
Comment by martinjrobins on 2017-06-12 at 17:13:54
I think GitHub issues would work well instead of a forum. Obviously a dedicated forum webserver would be most suitable for this, but its a lot of work to maintain a server for anything, and I think the trade-off is worth it.
Con:
You can't refer to a new commit on a GitHub issue until buildbot pushes it :(
Pro:
If we want the GitHub repo to be the public face of Chaste, then it is nice for users to see a lot of recent opened/closed issues, shows that a project is active and the developers are responsive. So good advertising!
Comment by jmsgrogan on 2017-06-13 at 07:54:09
Definite +1 for Github issues, it is the first place I go to if something isn't working in other codes and will show up better in Google searches.
Comment by mirams on 2017-06-13 at 09:27:50
Not sure. A Q&A site with:
- votes,
- the best answer at the top so you don't have to read the whole correspondence,
- the ability for us to edit answers things change over time,
are all very very useful, and those things are the main point of moving away from a mailing list rather than simply not losing issues. There must be loads of Q&A open source things by now?
Comment by jonc125 on 2017-06-13 at 09:36:40
You can edit comments in GH issues. Not sure about voting, and it's possible to jump to the end of a thread!
The main downside of using an open source Q&A is that we have to host it and maintain the server, applying updates, etc. And we have no-one to do this.
Comment by mirams on 2017-06-13 at 09:43:45
Is there some way to edit someone else's comments on a github issue? (Quite often on stackoverflow the question as well as answers get edited to make more sense!).
Comment by martinjrobins on 2017-06-13 at 09:46:53
I just tried it, and I can edit someone else's (another collaborator on the same project) comments on an issue.
Comment by MichaelClerx on 2017-06-14 at 09:58:06
You're all talking about issues, but the ticket was about user questions :-)
Github is for issues that need resolving. As soon as an issue/bug/feature-request is resolved it disappears. It's main users are developers.
The ticket here is for a user Q&A, to help people use the bug-free software. So main users are end-users, and answered questions will be more popular/relevant than new ones.
Comment by martinjrobins on 2017-06-14 at 10:09:36
but Github issues end up being a defacto user forum for many open source projects. You can label issues depending on what they are (e.g. bug, help wanted, question, or any custom label), and you can still see closed issues (or just don't close FAQs)
Comment by MichaelClerx on 2017-06-14 at 10:22:44
You can do it, just not a good idea
The first option in the tab menu is code, 2nd is issues - not questions!, 3d is pull requests. There's a button for forking right at the top. To see previously answered questions you need to remove the "is:open" filter manually, OR the entire community has to remember not to close them. Totally geared towards developers!
There's a case to be made for Chaste users typically being developers, sort of, but that should become less and less the case once the core stabilises and people start using it via PyChaste or super-easy-c14 right?
Comment by martinjrobins on 2017-06-14 at 10:31:00
I think a dedicated user forum is better than github issues, cause that is what it is designed to do, but not worth the extra work in maintaining a server (or paying for a hosted solution). But if you're volunteering to do this, I think discourse is a good solution (https://www.discourse.org/) ... :)
Comment by fcooper8472 on 2017-06-14 at 11:24:53
I agree that github issues aren't perfect. But, I really think it's worth stressing that we don't have anyone in a position to be responsible in the long run for another instance running on chaste.cs. We are already, I think, likely to run into issues with trac etc, 18 months from now when we need to upgrade the OS on chaste.cs.
The benefits of github are that:
- We already use it
- It's almost certainly going to be around longer than Chaste
- It's the de facto standard place for people to ask questions about the software hosted there
The 'middle ground' option would be to create an 'issues only' repo on Chaste: maybe named User Questions or FAQ Blog, or similar, that we advertise as the place to ask and answer the sorts of questions we currently get on the mailing list.
We could then decide to never close a question, if that makes it easier for people to find the answers, and it would separate 'dev' issues from user questions quite nicely.
Either way, unless anything changes drastic changes, I think the options are realistically between continuing with the mailing list, and using github.
Comment by mirams on 2017-06-14 at 15:56:58
Michael will have a play with discourse (which is free if you host it yourself) on chaste.cs.ox.ac.uk at some point, and can use third party google/twitter/facebook logins so we wouldn't have to manage that. Maintaining owncloud on trix has been pretty easy, even for me who doesn't understand web servers, so I think it is worth the minimal effort for a much better system.
Comment by MichaelClerx on 2017-09-15 at 19:42:41
Question2Answer example is up and running on https://chaste.cs.ox.ac.uk/questions
Let me know if anything else on https://chaste.cs.ox.ac.uk/ is broken!
Comment by mirams on 2017-09-15 at 22:17:20
When you press the button to 'flag' a post you get asked to confirm your email and it sends a link.
Only problem I've found is that you can't confirm, because this email has a http:// instead of https:// link. If I manually changed it, then it works.
Can we alter apache settings to re-route http to https for /question?
Comment by MichaelClerx on 2017-09-15 at 22:59:23
I'm not sure! I've tried making apache reroute http:// to https:// but it didn't seem to work.
Is it something to do with the greater oxford/cs infrastructure? Our webmail also hangs indefinitely if you use http instead of https...
Comment by mirams on 2017-09-15 at 23:50:59
Replying to GaryM:
Only problem I've found is that you can't confirm, because this email has a http:// instead of https:// link. If I manually changed it, then it works.
I think I've fixed this problem in the admin settings by telling Q&A that it lives at the https:// address, so now it should be emailing links with that in.
Trac seems to be a bit slow, someone who knows things might want to check the new config!
Comment by MichaelClerx on 2017-09-16 at 00:10:07
Trac is very very slow from here! Not sure why though, haven't touched it...
Comment by MichaelClerx on 2017-09-16 at 00:11:33
Hold on, with the Oxford VPN turned off trac is really fast again!
Comment by fcooper8472 on 2017-09-17 at 20:15:33
Am I right in thinking that you need to register as a new user? Is there any way to integrate logins with trac?
Comment by MichaelClerx on 2017-09-18 at 07:53:24
It can be done by modifying a bunch of scripts! http://docs.question2answer.org/install/single-sign-on/
Should be easy provided someone knows how tracs user system works!
Comment by jonc125 on 2017-09-18 at 08:01:09
Trac just authenticates against an apache htpasswd file.
Comment by MichaelClerx on 2017-09-18 at 08:14:39
Really? So when I create an account for trac it stores my email address somewhere and then modifies the .htaccess file? When I log in I don't see the old-school browser popup login you usually get with an .htaccess authentication, how does that work?
Comment by jonc125 on 2017-09-18 at 08:19:28
.htaccess is different from htpasswd - the former is an apache config file, the latter is just a user/password store. Trac doesn't use HTTP Basic Auth (which is what pops up the box - although there are a few pages on the wider Chaste webserver that do), it just shares the user/password file with Apache. Email addresses etc are stored within Trac's database. There's some code in the old test infrastructure that reads email addresses from there IIRC, so it can tell people when they broke the build.
Comment by MichaelClerx on 2017-09-18 at 09:01:00
Ah, thanks! I can't find any trac integration plugins, so it looks like we'd have to do it ourselves.
Would require:
- Letting q2a check users/passwords against tracs database
- Letting q2a get email addresses from tracs database
- Letting q2a create new users -or- letting it redirect to a trac page instead
Comment by MichaelClerx on 2017-09-18 at 09:21:46
So not sure how that would work out with maintenance...
Comment by MichaelClerx on 2017-09-18 at 12:17:57
There's a (third-party) OpenAuth plugin, but the docs look like it's a bit of work to set up!
https://github.com/alixandru/q2a-open-login
Personally would just have users create a new account at this point...
Comment by mirams on 2017-09-18 at 12:56:40
Hmmmm, doesn't look too bad? Might be worth the effort to have something that will require one less username to worry about...
Comment by MichaelClerx on 2017-09-18 at 13:38:01
As a representative of the user community, jmpf would like the user info to come from trac.
This would mean:
- Getting the usernames/pwhashes from a file (easy)
- Redirecting registration requests (easy, but a bit annoying as users will be redirected, then need to register, then need to go back to q2a and login)
- Getting email addresses from trac's database (could be tricky, probably fine)
Comment by jmpf on 2017-09-18 at 13:46:36
Replying to MichaelClerx:
As a representative of the user community, jmpf would...
Thanks. That's prompted me to add to the ticket.
Absolutely. My view is that adding the hurdle of an extra account sign up and log-in will cut the number of potential contributors (by as much as 75%). Since most reliable people to answer questions are all in the current trac population and the same website is using svn/trac authentication for svn, trac, git, buildbot, doxygen? then it's clear that svn/trac authentication ought to be the natural solution.
Comment by mirams on 2017-09-18 at 13:50:21
Hmmmmm, one problem is that not all trac users even have email addresses in the system... and a Q&A system isn't good if you have to go back and manually check for replies.
Comment by MichaelClerx on 2017-09-18 at 17:00:10
As far as I can see there are 278 people with a trac password and 232 with an email address (P.S. I've figured out how to do that ;-)
Comment by MichaelClerx on 2017-09-18 at 17:52:31
With the current architecture I think it's impossible to require trac users to have an email address (because it uses http authentication, which doesn't know/care about email).
Comment by MichaelClerx on 2017-09-18 at 17:57:10
Sorry for spamming, but this just occurred to me:
If you don't have a trac account and we go with the openauth implementation. Then we're potentially asking users to sign up for github/google whatever, instead of our own user registration, which you'll need to sign up separately. That seems wrong to me.
Comment by mirams on 2017-09-19 at 08:19:44
I think we might be worrying too much about this. If we do ever move Chaste to github or similar, then it will help to have a non-trac reliant system here. It takes about 10 seconds to sign up, and you can make that login identical to your trac one if you like.
Replying to MichaelClerx:
If you don't have a trac account and we go with the openauth implementation. Then we're potentially asking users to sign up for github/google whatever, instead of our own user registration, which you'll need to sign up separately. That seems wrong to me.
As far as I can work out, the oauth plugins work alongside the existing Q&A login (I played with enabling the inbuilt facebook one, and it added a new button for login with facebook), so we would still allow it to work as it does now, but just give more login options, including Stackexchange incidentally. I would see if that oauth plugin can be made to work in less than an hour, regardless of whether we try to sync the in-built login with trac.
Comment by MichaelClerx on 2017-10-12 at 09:28:20
Have tried to set up login via google, but that doesn't seem to work (for an unspecified reason, so bit stuck with debugging, have asked on their own q&a). The github login they advertise is nowhere to be seen in the admin pages so that's not looking great either.
Have had a look at integrating with trac and think this will be tricky (it doesn't want to simply read tracs user/pw files, it wants to have trac handle the whole login, and then share this session somehow. Would require more knowledge of how trac works than I have).
So how about we just keep it as a separate login? It only takes a few seconds...
Comment by mirams on 2017-10-12 at 09:54:30
I am fine with a separate login, you have to sign up for the mailing list separately at the moment anyway.
Comment by MichaelClerx on 2017-10-12 at 10:00:42
Good! So shall we start migrating some of the mailing list questions then?
Comment by mirams on 2017-10-12 at 10:34:16
If others agree!
Comment by fcooper8472 on 2017-10-12 at 10:47:13
I'm definitely up for giving this a go, but do worry somewhat about the takeup.
If we could get the Google (and other) logins working alongside, I think that would be great to have, but let's at least test the waters...
Comment by mirams on 2017-10-12 at 11:01:18
Presumably we could first of all tell the mailing list people about it, then after a couple of weeks set up the mailing list to auto-reply to posters telling them to go to the Q&A site instead?
Comment by fcooper8472 on 2017-10-12 at 13:05:30
Potentially very important: is there any facility (or can there be facility) for Markdown support (or else something similar), so that we can easily write code blocks?
If we can't format code well, it might cause issues!
Comment by MichaelClerx on 2017-10-16 at 09:13:28
Code formatting works now, and has support for C++, Make, CMake, Bash and ini files (it should be able to auto-detect these). The formatting happens via javascript, so doesn't always happen instantly I'm afraid.
Markdown parsing is done by code from stackexchange, so follows the same rules (use indenting to start a code block).
Comment by mirams on 2022-10-24 at 15:14:29
Github now has special discussion pages that seem perfect for this, so that's now a very sensible option, and means they will have good ways of dealing with user authentication and spam etc. So we could switch these on.
Comment by MichaelClerx on 2022-10-24 at 15:28:59
Sounds good to me!
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent