Page MenuHomePhorge

Consider using the Ponder module on Phabricator
Closed, WontfixPublic

Description

We should consider using this module on Phabricator (in case people don't know yet, it's actually already installed here). It serves as a question and answers platform and although it might not be nearly as well designed as say, Quora of Stack Exchange (or even say Discourse, free and open source software that's even though designed for discussion, still works quite well with Q&A), it does do what it says it does. Some reference links:

Current disadvantages (not all are listed):

  • Questions can't be closed as duplicates as of another ( to do that you'd have to mark the question as invalid / declined, reference to the task, and then manually add all subscribers to the other task ) An easy way for marking it as a duplicate like you can with tickets in Maniphest would be essential ( in my opinion) This is being tracked in https://secure.phabricator.com/T6921, although it should be noted that it might not be implemented until v2, stated by Chad (official software engineer for Phabricator)
  • it's still in beta (from my understanding at least, let me try to find the ticket again that mentioned this) - this means that it's bound to change and might not be reliable. However if we actively use it this means we could possibly find tickets to report upstream and hopefully help get it improved by reporting them if we decide to use this module extensively
  • Complaints by users that Phabricator and/or Ponder isn't user friendly and more dev-oriented. We should figure out in a separate ticket on how we can provide for onboarding people for learning the knots and ropes of the Phabricator interface.

Advantages

  • Instead of handling two ticketing applications at once (OsTicket and Phabricator), we'd most likely only have to use Phabricator more, potentially meaning easier to track things
  • From my understanding, you can still set custom policies like how you do with tickets on questions as well, in case the visibility needs to be limited to a select few.
  • Pofenrially this could also prevent less confusion for the end user as-well, as in the end-user doesn't have to figure out when to use Phabricator and when to use OsTicket. Since currently ShoutWiki uses two applications for ticket management

I'm not sure how creating a question via email would work with Phabricator. Phabricator does provide a Conduit API which allows many actions to be performed, such as APIs for Maniphest. Here's the docs:
https://secure.phabricator.com/conduit/

Figuring stuff out like being able to create a question and automatically send it to Ponder would require lots of research in the internals of the Phabricator software and how the API works. Here's some other related tickets that talk about Ponder and emails:

There's also some other stuff I might've left out, this ticket is currently somewhat rushed but I wanted to push it out because otherwise I might forget to submit it in the future. Please give feedback on what you think and ask questions :-) thanks!

Event Timeline

Instead of handling two ticketing applications at once (OsTicket and Phabricator), we'd most likely only have to use Phabricator more, potentially meaning easier to track things
Pofenrially this could also prevent less confusion for the end user as-well, as in the end-user doesn't have to figure out when to use Phabricator and when to use OsTicket. Since currently ShoutWiki uses two applications for ticket management

The user doesn't have to figure this out. The user goes to osTicket because 99 times out of 100, that's the correct place. If we could easily disable user talk pages for staff, I probably would have done so by now. In my opinion, ProblemReports creates more hassle for me than the extreme rarity I have to refer people here.

The vast majority of requests we get from users aren't bug reports, they are changes to wiki settings. That is why almost all of the issues filed here are filed by staff. Phabricator is a project management tool, not a support ticketing system.