Yes, to combat spam, generate useful metrics, and make it easier for users to turn into contributors (with FAS creation as the first step), we’ve decided to limit logging in to FAS only.
Unfortunately, there is no clear way to migrate information from askbot to Discourse—we’re not hosting this instance either, so we don’t have access to the low-level database etc. anyway. So, we’ve worked on moving common questions to the quick-docs, but that’s all. We’ve all had to drop the karma/badges and start over.
Discourse, however, has (in my opinion), an even better trust system, so I do expect new users will quickly be able to go through the gears and earn their badges and permisisons too.
I have been using new ask fedora platform for past 3 days and definitely this platform is clean, fast and easy to use. I have one suggestion. For solved topics, we have a grey tick box in beginning of the title. Is it possible to have a green tick box instead of grey? Because this will visually give immediate understanding and distinguish topics between solves and unsolved very easily?
modern interface, Discourse is nice, the old platform was buggy and dated
conversations will allow more engagement versus being restricted to questions and answers
The only con I can think of is that I had a bunch of useful questions/answers bookmarked in the old Ask Fedora platform that I may miss! It would be nice to keep that information somewhere as a useful reference.
Are they up-to-date?
Are they older? or
Did they make reference to EOL release?
if yes., try to forget, we need here only reliable and up-to-date information, altought we moved the sticky question to quick-docs → Fedora Quick Docs :: Fedora Docs, If you do find any information that you think are common queries, please open a ticket or pull-request at the quick-docs project. Overview - fedora-docs/quick-docs - Pagure.io
We havent put that up there because we do not know when it’ll go down and so it should not really be used as a stable reference. We’d rather let people ask these questions again and answer them here.
If a question is very common, it should be put on quick-docs where it will be reviewed to ensure correctness periodically.
It’s often the uncommon questions and solutions that are most precious to find. I understand the desire to promote the new site, but with the old one being read only, I don’t think it would negatively impact adoption.
On the other hand losing old, sometimes hard to find, resources silently isn’t fun. I guess there’s the idea that things on the internet are there mostly forever. It’ll be sad to see that trove of questions and solutions vanish. Still, quite happy about the new site.
We can’t really afford to keep it forever. Even if we were hosting it locally, we’d have to keep the software running and patched against security vulnerabilities, and the infrastructure team is overstretched.
I agree that the long tail of rare situations is one of the important functions of a help site (as opposed to having everything in the docs), but… not always much we can do.
There’s no straightforward way to do so other than manually posting in both places.
So, I understand everyone’s reaction that “we’re losing all this information”, but I really don’t see that as an issue at all. We’re not trying to come up with a database of informatoin like the stackexchange websites. Personally, I don’t want users to search, copy-paste, solve. That model works well for developers who are short on time and are focussed on “getting the job done”. Here, in the Free/Open source community, thought, the process of diagnosing the issue is far more important—it has an educational component, and a community building one which are extremely paramount.
So, like the IRC,I suggest every topic be treated as a new one, even if it has come up many times before. Let’s speak to the poster, help them learn how to gather information to find out what the issue is, and then help them arrive at the fix.
I am not saying that we don’t make the information accessible, but that’s not priority for me somehow.
(You will notice that quick-docs are also focussed on “how to do X” not on solving issues)
Right now, I don’t see how to down-vote a post, although I don’t want to as yet. I do hope that Discourse doesn’t make down votes meaningless, the way Discus did. It used to be that you could see how many down votes a post had, and who made them; now, only the moderators can, unless voting down goes straight to /dev/nul. We need to know about down votes, as it can help us judge the quality of a reply, especially if we’re considering trying any advice in the post.
Discourse does not do down-votes. It relies on positive upvoting. So the idea is to stress on good posts, and not pay much attention to ones that are “not good”.
You can flag posts, though, and moderators can look at flagged posts and deal with them appropriately. There are various actions mods can take, and suggestions are noted in the moderation guide.
More on this in the discourse user guide (included in the #start-here introductory posts). You can read more on why Discourse decided to be so on the meta forum.
FWIW, I agree with their decision to not have down-voting. As we’ve seen from various platforms (including askbot), downvoting tends to add a negatve environment to the community.
Having the ability to down vote a post may or may not be a good idea on a board devoted to discussion of subjective topics such as politics. (I have a definite opinion on that, but it’s not relevant here.) However, this is a tech support forum, and the ability to down vote a post if you think that somebody’s advice is wrong can be valuable. Yes, you can always add a post expressing your views, but there are times that I’ve seen somebody post an “answer” that directly controdicts an earlier post that was marked as the Right Answer or that ignores information that was in the original question. In a case like that, voting the post down should be sufficient, as later readers should be able to see for themselves what was wrong with the post. Also, not being able to down vote makes it look like disagreement is being discouraged in a rather heavy handed way. Be that as it may, I plan to continue using this site and giving advice if and when I think I can help.
It’s not a tech support forum in the same way as stackexchange IMO. As I said in an earlier post, our focus is also on educating each other and encouraging usage and participation in FOSS. Downvoting does not fit this aspect of community development.
I think of it differently. A downvote says nothing at all about why the post “wasnt good”. It is much better to post explaining why a certain post " So, we’re not discouraging disagreement, we’re encouraging discussion which really is the foundation of a FOSS community (a community in general).
Our conversation here is a great example of this—if you or I simply downvote each others posts, we never discuss the way forward