I'm a little perturbed at seeing this module because you are essentially forking the userpoints community without justification or without an attempt to collaborate. This is an extremely odd move from two people that are highly active in the community and I'm curious to know the reasoning behind this decision.
http://drupal.org/principles

The userpoints module has an active issue's queue in which you may post your requests for reduction of "Baggage" and your feature requests. As a group we can decide what should/should-not go into the core module.

Userpoints also has a group http://groups.drupal.org/userpoints wherein you can start discussions on the structure of the module and provide suggestions, feedback for moving forward.

I have searched through both of these and neither of you (the CVS committers) have made an attempt to collaborate in either way which is highly confusing because the two of you are highly active in this community.

So I ask.
Why don't we collaborate on a single module?
Lets work together to create a single module that is useful to the entire community.

Comments

kbahey’s picture

kbahey commented

Indeed, why not collaborate?

I agree with Jacob.

When we met at DrupalCon, Charlie had some concerns on Userpoints, and I asked that he posts issues and better yet, patches of what he found. That has not happened.

This is not a good example for others.

As for the "baggage", we would like to know what it is (ideally as issues in userpoints queue). It is really very modular and we stripped it down to an API. Don't want views integration? Don't enabled userpoints_views. Don't like workflow-ng integration? Don't enable that module? Don't want XML-RPC? You don't hav eto enable the userpoints_services either.

If your concern is the presence of a transaction file, then we can work on making this optional via the API, or a pluggable userpoints_lite.module that is API compatible with userpoints.module, but skips the transaction stuff.

The API is really minimalistic. There is a lot of optional stuff that you don't have to use if you don't want to. One of only 2 calls is needed (retrieving points, adding/subtracting points), everything else is optional.

The README.txt file has an API section describing this. If you take a look at this userpoints presentation, there is a case where someone wrote a couple of modules for userpoints in a few hours! And that was before we had the simpler 3.x API even.

Please reconsider concentrating our efforts on one project rather than fragmenting our efforts and confusing people.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Title: Why not collaborate? » Why not collaborate - OR at least a more constructive project description

While I generally agree that collaborating on existing projects is better when possible, I'll also allow that there are times when you just have to start over. Diversity of approaches is a good thing, as long as it is intentional and well described so that users are not confused.

In this case, users will be quite "confused". What does "baggage" mean? How is it "lighter weight" than a module which, as Khalid points out, is already relatively light weight?

So, if you have some good reasons why you need to split the modules then I think that is OK but you then have a responsibility to really guide useres in their selection between the two modules.

dmitrig01’s picture

dmitrig01 commented

I'm sorry about this.
I was not the one whose idea it was to make a new module, I just kind of played along (I've never really used userpoints myself).
However, I'll be using it on another site, so I think I may go ahead and post some patches.
I'm all for working on userpoints, I just was (and Charlie too) questioning how willing you would be to accepting patches. Since I see that you are concerned and very willing, I will start posting patches.
Dmitri

cwgordon7’s picture

cwgordon7 commented
Status: Active » Postponed

I basically consider this an experimental module. I intend to do funky things here, and then supply them back as patches to the userpoints module, or perhaps even a start-from-scratch userpoints drupal 6 branch. But as of now, there is no release, nor do I ever intend for this to be a release. I have updated the project description.

Postponed on the collaboration. Let me be clear about my intentions with this module, though.

jredding’s picture

jredding commented

Thank you for providing a better project description and if you feel the need to create a new module that is entirely fine and is exactly what drives OSS.

I think the project description is a bit better although I would prefer that its incredibly clear that the code as it currently stands within CVS is not compatible with userpoints nor any of its contributed modules. The functions have been renamed, the API reverted to version 2.x, hooks are missing and the table structure is different.

There is however a lot of really good work going into this module and I would love to see the time being into a single userpoints module that can take advantage of the existing community and the existing group of contributed modules instead of this "experimental module" .

The additional permissions have been requested for a long time but noone has had time to code them into userpoints but you have (which is awesome) as well as the fixes to some of the other functions.

I want it to be extremely clear here. Userpoints as a module is very open to collaboration and if you look at the issue's queue most of the patches submitted are worked into the core module.

Out of collaboration I could see a very, very strong version 4 coming out of it.

The choice and the ball, as they say, is in your court.