After testing answers I decided that I didn't feet my needs due to usability concerns. I wanted a closer version of StackOverflow's system. Thats why I created a module that, even having the same functionality, differs in usability and architecture: http://drupal.org/sandbox/ALMADEWEB/1757352
You ca see a demo here: http://qas-demo.almadeweb.es/
Following the ethos: collaboration rather than competition I propose joining with answers.

Diferences of qas with answers (I believe those are all advantages of qas):

  1. qas has all base modules (qas, qas_best_answer, qas_voting and qas_userpoints) within one module directory (qas). (does not make a big difference but is handier and more time saving)
  2. qas is not based in features module and has no dependency on strongarm module either.
  3. qas has less dependencies, as is more code-driven: not need of eva (view is inserted in node_view), does not use nodereference_count (using views agregation instead), nodereference_url
  4. qas is based on entityreference and not in nodereference (references), as is suggested in references module project page (http://drupal.org/project/references). I assume that you are aware of the changes in nodereference future: http://drupal.org/node/1858350
  5. qas views are incremental hook_views_default_alter, while in answers each base module rewrites the views defined as default. http://drupal.org/node/1014774
  6. best_answer based on flag module what makes it more powerful (direct integration with rules, integration whith views and other modules), flexible (settings by UI) and easier to maintain. Answers, in contrast, has a custom solution based on fields.
  7. Clean use of comments with usability enhancements in tpls of qas_theme (a prototype, use ready though).
  8. Answer node creation form at the bottom of question page. I consider this a usability enhancement while a way to avoid the introduction of data errors on related question form input.

I think that qas will be easier to maintain than answers (points fron 1 to 6) and easier to use (points from 6 to 8).

I leave it here for your consideration.

Cheers
Alessandro.

Comments

luksak’s picture

Version: 7.x-3.0 » 7.x-3.x-dev
Priority: Minor » Major

Thank you for posting this. I kinda had the same feelings when I started my Q&A stackoverflow.com cloned site development three weeks ago. I also customized answers a lot (did you actually use it as a base?). But I've chosen a different approach. I did most of the things using site building. I created my own views and used panels to display them. I also created a few notifications using http://drupal.org/project/notifications. My main concerns are not using entityreference and flag. This automatically brings a lot of flexibility to the module. And I also agree with most of the other things on your list. But I think we should start to use the proper data structure. So the fist thing would be to migrate to entityreference. I already created a issue for that: #1858350: Migration to entityreference

The other part is that you did code most of the functionality. For some thing it makes sense. For others it doesn't. I don't understand why answers is sending emails out in code. This should be implemented with rules. As I said, notifications is the perfect tool for this. Let's use it!

Another bad example of hardcoded functionality is displaying the login form when visiting node/add/question as an unauthorized user.

Also we need to make sure that it all integrates with panels an views.

Another topic would be if you intend to publish your sandbox as a project. Since answers has 400 D7 installs, I would suggest to implement the improved design patterns from QAS to answers. What do you think?

We should create a meta issue or just use this one to track all different issues.

Looking forward to hear from you guys!

AlessMascherpa’s picture

Hi Lukas,

Is nice to see there is people with interest :)

QAS doesn't use answers as base. It is inspired by it though. QAS is written from the ground up. Is based in Content types so you can modify questions and answers with Field UI. Also based on views, so you can modify views or integrate them with panels, OG, or other modules from Drupal ecosystem.

My first choice, will be to merge QAS into answers, as you mentioned, rather than upgrading QAS to full-project. QAS and Answers have the same goals. Therefore last decision is @chipcleary's, the answers maintainer, though.

I feel that QAS/Answers should be as basic as possible. Notifications is a great module but also complex. I feel that this configuration can be done in complementary modules/features.

Regarding your comments about sending mails and redirecting users to login pages in a hard-coded way, I imagine that you are talking about Answers. QAS does nothing of this. You can configure this behavior with rules and permissions.

Cheers,
Alessandro.

chipcleary’s picture

BTW, as a heads up, I believe merging is a good path. I have installed QAS, done an initial review of the code, and done an initial review of the interface.

In sum, I agree with Alessandro's assessment in #1 above. QAS is a cleaner implementation. The improvements in the UI are important. This is even a particularly good time to make a shift since we need to make a change in architecture in the D7 version in any case due to entityreference, as Luk raised in his issue.

I would like to spend some more time over the next week to consider the differences in functionality. Answers does provide for some features that QAS does not. I'd like to map out what those are and collaborate to identify what path(s) we might take on them moving forward. The discussion above about hardcoded vs. Rules vs. Notifications is an example.

(As a side note, I also agreed with Alessandro's point above, the "bad hardcoding" Luk mentions is part of the current implementation of Answers, not QAS.)

luksak’s picture

Yes, I was talking about answers when I mentioned the hardcoded stuff.

@chipcleary: Exactly, do a review of the differences between the modules. Then we should define the goals we want to accomplish and create a roadmap.

You are right, we should keep functionality such as notifications in contrib modules. We should review functionality in answers core and think about moving it to separate modules.

AlessMascherpa’s picture

Thank you @chipcleary for the interest and nice words about QAS. Is always nice to have good opinions about your work. Reviews, either good or bad, are always welcome. Part of my interes in joining QAS with Answers is improving the module.

Yes @Lukas, we have to define the module goals and create a roadmap. Before we can do that, we have to figure out, decide and organize, how to merge both projects, and list the main diferences between them. After that we can decide what goes in Answers and what goes in Answer sub-modules or external modules/projects.

One main difference between QAS and Answers, is that QAS is not based in Features. It has to be hand coded. Exportable configuration of Views, Rules, etc, helps a lot, though. Features is great but I don't know if it can offer the flexibility needed to build QAS and to keep things separated in different modules. As I see it, the options for merging are two:

  1. Merge QAS as a new Answers branch an just replace "qas" with "answers".
  2. Create a new Answers branch. Continue with Features and Strongarm as source for content types, views, rules... configuration and export capabilities and try to extend it with the .module file to have QAS usability and architecture enhancements build on it. (I don't know where this path goes, but it could be an interesting one)

Either way, Features can still be used in adding especial case functionality and configuration, especially in external modules. As QAS, like the three main Answers modules, is based in nodes, views, rules, flag, rate/votingAPI and user points, I think that many of the existing Answers modules will need little adjustment to be adapted to QAS If we walk the first path, and maybe none if we take the second one.

Things that would require more effort will be:
- Migrating from previous versions to the new one
- Drupal 8 version. I have no clue, but think that exportables, features an configuration management have improved a lot in D8.

Cheers
Alessandro.

migs13’s picture

subscribing

luksak’s picture

@chipcleary: Could you make a proposition how to proceed on this?

As a site builder I like working with features. Even though not a lot modules providing similar set of tools (views, content types, etc.) have a dependency on features. So maybe we should try to drop it? I can't really judge this one...

Let's keep this conversation going.

chipcleary’s picture

Hi all, just a quick update after some time.

I do plan to proceed with this ... and expect to start shortly. My basic plan is:

  1. Define 7.x-4.x to be based on QAS
  2. Create a quick port of what Alessandro has provided
  3. Extend it to provide notifications when people answer questions
  4. Create a method to move data from 7.x-3.x to 7.x-4.x
  5. Create a method to move data from 6.x to 7.x-4.x
  6. Update Relevant Answers (a not-very-much used module which depends on Answers)

Help very welcome with this shift. I understand from Alessandro that he will not be spending time with Drupal in the near future ... so cannot pitch in. Would you be interested in taking on part of this ? In particular, I'd love help on the data transfer approach (#4 and 5).

luksak’s picture

Great to hear this. looking forward to see this! Let me know if you need any feedback.

ivan zugec’s picture

I can help out. I just played around with QAS and it looks pretty good and I think it's a good direction for Answers.

@chipcleary, What do you need help with? It looks like you need help with version upgrades (fun, fun) :). That is something I can look at.

In the mean time, should I create an "upgrade" issue?

chipcleary’s picture

Hi all, I very much appreciate the offers of help.

Here's how I suggest we tackle this. I have now created a version 7.x-4.x of Answers. This simply takes the work that @AlessMascherpa did on QAS and port it directly. Very few and minor changes to that code.

So, we're started.

Next, I will create feature requests for the work items to be done. If you are interested in pitching in, please either:

  • Test the 7.x-4.x branch so I can release a snapshot version (7.x-4.0)
  • Pick one of the feature requests for the 7.x-4.x branch and work on it.

I'd particularly appreciate help on the import-export feature so that people can migrate to the new branch.

How's that sound? If it's reasonable, we can close this issue and start work on the features.

chipcleary’s picture

Status: Active » Closed (fixed)

I'm closing this as an "open issue" since the work is underway. All who would like to contribute can do so by making feature requests or implementing feature requests for 7.x-4.x-dev.