grayside / crowd_qa Goto Github PK

Time to upgrade the preprocess function in this, and about 12 other things.

Use Views Customfield to programmatically invoke a view to list comments.

When a Question is pre-set on a new Answer nodeform, preload any taxonomy terms from the Question node and hide them. Only a Question form should have taxonomy fields.

Possibly, will add a vocabulary to the Feature and limit this behavior to that one vocabulary.

Note: Ideally, on hook_nodeapi update of a Question, all referencing Answer nodes would have their terms updated.

Figure out how tagging integration should work.

This is an example of an enhancement that is beyond the scope of this project. If this can be limited to documentation, good.

Otherwise, if it takes a little strongarming, but keeping whichever module out of the dependencies list, so be it.

I kind of like and dislike aspects of both of these:
http://drupal.org/project/suggestedterms
http://drupal.org/project/tagging

This project is starting to look pretty epic in size, and as I think of more and more tweaks to make it cool, it only scales up. I think it Crowd Q&A as a project should be broken up into multiple pieces around a core Crowd Q&A functionality. This will allow easier management of the different elements of the system, and also allow site builders to more easily implement alternate functionality for a given subsystem.

• crowd_qa: Question and answer content types, core views, reputation system.
• crowd_qa_discovery: Adjusted search index, taxonomy integration.
• crowd_qa_users: Hall of fame view (block with highest rep users), user page with answers sorted by accepted & voted up, domain mastery by taxonomy terms (domain mastery titles). [Challenge: How to add the titles back to the user info of crowd_qa views? hook_views_pre_render_alter() maybe.]

Votes are great for community judgement, but there's nothing like the asker actually approving an answer to pseudo-close the question.

• Answered questions should be themed differently on listing displays.
• Answers are identified via a nodereference.
• Nodereference should be handled invisibly, by a swishy widget the question owner can see.
• The accepted answer needs to sort to the top.
• Everyone can see the accepted answer, but only the question owner can mark it.
• In some alternate universe, something atrium-specific should signal an accepted answer via Atrium Message.

The plan

• Use the Mark module or similar +1 mechanism. Flag module if it's exportable.
• If marked, counts as a vote, or maybe even more, for userpoints to the answer-giver.
• When marked as a final answer, a nodereference is updated from the question to the answer.

warning: htmlspecialchars() expects parameter 1 to be string, array given in /Users/abr/Workspace/drupal/atrium-1-0-beta-8/includes/bootstrap.inc on line 857.

Overall reputation should be included with all users, domain-specific (taxonomy-term specific) titles should be calculated based on points/accepted answers for specific terms.

For example, the "Linux" tag.

• 200 reputation in linux-tagged questions = Expert, 500 = Master, 1000 = Guru, 5000 = Ninja.
• Such titles (and levels) should be configurable.
• In Linux-tagged questions, the user (or his answers) should be titled as "Master of Linux".
• Some user-centric block to list all the "titles" earned.

Open Questions

• I expect this will involve a bunch of queries to calculate per user, we might want to process this via cron.
• In the case of a node with like 5 taxonomy terms, how should it be handled differently so it's not ugly?
  1. Instead of display the title prominently, burry it as a tooltip on the user's signature.
  2. Create fancy "badges" around the taxonomy term according to the title of the user, and display those around the answer, perhaps along the bottom or lined up vertically along the right side.
  3. Just list the highest ranked title, and allow the user to click through to a profile page to see the full expertise list.
  4. Somehow average the standings to calculate a rank specific to the current issue. (This seems both expensive and not useful.)

Modules worth checking.

• Userpoints Contributed Modules
• User Badges

Subscribing to a Question content type is really about subscribing for notifications about new answers.

I suspect this will be both difficult, and involve alter hooks. Notifications about the post needs to be replaced with notification from a view, or about Answer content type with a given nodereference field.

VotingAPI policy is to leave this up to individual voting widget modules.

Vote Up Down has a pending issue with a patch and an architecture-based rejection of that patch. Something might be done.

http://drupal.org/node/554360

When writing a question, it would be awesome if the site could let you know if similar questions have already been asked. Doing this would probably be a new & separate module, but I am noting it here as a feature request to enhance crowd_qa (not a dependency).

There are two approaches to this.

Autocomplete Title Field

This is possibly the most straightforward. Convert the title field into an autocomplete field, pinging against every other question asked. Other questions should be supplied by a programmatically executed View. If possible, the View should narrow the results by Space.

Why does this suck? Because we don't want people to actually ask the same question, we just want them to know the other question exists and click through to it if it seems helpful.

Ajax Views Search

Some bizarro thing. There is a View that runs a search with your text against (preferrably) the search index. It's results should also return in an ajaxy manner and inject a few results below the title area.

This may be a new module, but I have seen enough ajax + views modules that I've never really looked at that I can't be sure. It might simply be part of the future crowd_qa_discovery module

Views template or Views plugin?

Implement crowd_qa_preprocess_search_result(), and override the link depending on the node type.
Things needed: field_crowd_qa_question needs to be available, or queried, to build the link.

http://api.drupal.org/api/function/template_preprocess_search_result/6
http://api.drupal.org/api/drupal/modules--search--search-result.tpl.php/6

Post comments directly in the Q&A page with automatic ajax-y insertion.

• http://drupal.org/project/ajax_comments

Unclear how well it will work given the way nested comment Views are the plan for Answers, but that should satisfy the Question comment mechanism.

A central administration console would be very useful, given the complexity of this module. What I mean is to pull the specific form settings related to how this module behaves into a single form with a lot of duplicate entries. This would replace a lot of documentation telling people where to go to poke and prod the various settings relevant to crowd_qa.

It's kind of counter to standard practice.

Specific settings to treat this way:

• Karma (the votes to userpoints conversion ratios)
• Comments
• Voting Widget

Special complexities here: Duplicating the existing form widgets from the various admin interfaces, but adding to them the same access control that governs the admin form as a whole. Thus, if you need administrate votes or the like to tweak a setting, you still need that for this copy of the form widget.

A real wtf kind of moment.