Please transfer ownership of Voting module

What benefits does resurrecting this ancient project have over existing, and maintained, voting solutions like votingapi, fivestar, etc.?

@Morbus Iff: Good question, and thanks for considering this request.

First off, the voting module (if it were to be resurrected) would continue to leverage votingapi as it has in the past, and in no way attempt to do repeat/redo anything that is happening in votingapi.

With regards to fivestar, I think everyone would agree that it's the standard bearer for rating/voting modules. Despite this, there are some areas where it falls short. One specific example is that it is highly tied to the concept of star based voting (obviously by-design), which can be limiting if you wanted to implement other kinds of voting widgets.

There are a few different directions that I would like to see this (voting) module move... From a high level, I would hope that voting could become a facilitator module (for fivestar, and eventually other voting widgets) that would take care of things like defining voting axes and creating their relationship to different node types. Further, voting would attempt to be widget agnostic, allowing other modules to define and implement the actual widgets.

I would hope that voting
could become a facilitator module (for fivestar, and eventually other
voting widgets) that would take care of things like defining voting axes
and creating their relationship to different node types. Further,
voting would attempt to be widget agnostic, allowing other modules to
define and implement the actual widgets.

That sounds like things that would be included in an API. Why not make these enhancements to the voting API?

Why not make these enhancements to the voting API?

Indeed! I agree that some of what I've mentioned might seem better within the API itself, but Eaton (for reasons I tend to agree with) seems inclined to keeping votingapi lean and mean (see http://drupal.org/node/335668#comment-1126073). As Nedjo points out in that issue, one solution would be to add methods into votingapi that would conditionally load another module, thus keeping votingapi's footprint small...

If there is a strong consensus (that includes Eaton) of people who believe these enhancements ONLY belong in the API (ie votingapi), then I'm more than willing to focus my efforts there.

@Morbus Iff & greggles...

Did I address your concerns? Any further comments, questions, or thoughts here?

I still don't see any reasons to resurrect an old project.

From the description given, Voting would become a layer between a module like Fivestar, and Voting API.
If that is the case, could you give a description of the code the module would implement?

I'm not convinced that this is a great idea, but I don't think we should let our skepticism alone hold back someone who wants to contribute improvements. The VotingAPI has it's purpose and this is a way that enhancements to that API can be built, tested, and proven to be of value. Once that has happened then there is a chance that some or all of the changes could be incorporated into VotingAPI - let's give noahb's ideas an opportunity to live.

I have transfered the project ownership to noahb.

@noahb - the major drawback of this is the potential confusion that users will have when they try to understand how your module fits in to the larger world of modules available on drupal.org. I'm leaving this as "needs work" because you need to edit the project node to provide a description of the goals of the project and how it relates to the VotingAPI. Once you've done that, please mark this as fixed.

Thanks for your feedback. I appreciate (and hold) the concerns you've brought up, and I will make every effort to develop a solution that improves/simplifies the drupal landscape. As mentioned, there is no good reason to simply resurrect old code where other modules (e.g. fivestar) are already meeting our needs.

...could you give a description of the code the module would implement?

I'd like the voting module to provide these general features:
1) Definition, assignment, and management of voting axes (tags).
2) Object type assignment (e.g. node type, but also maybe users or comments?).
3) Voting widget assignment (i.e. provide a generalized framework for other modules to implement the widget used to cast a vote ).
4) Act as a testbed for features that could potentially be added into VotingAPI.
5) Anything else that can be identified as duplication... Ideas welcome!

@greggles: Thank you for taking a chance here. By no means do I want to add confusion, and if you or anyone else believes this effort is largely unneeded or taking the wrong track, just let me know and it's over (ie, i'll stop)... Would you like me to change the project description now, or first attempt to garner some community consensus about where I should take this before noting the changes on the project homepage?

@drawk: Thanks for your support!

@noahb - I'd say update it now. I've taken a first stab at updating it to try to take into account the ideas you've shared already so I mark this as fixed. Please feel free to overwrite what I've added, but keep at least some of the words of encouragement for "normal people" to use VotingAPI.