Because people can't wait .... :)
The Ratings/Review mod is a really complicated modification, and everyone has a different idea about what it should do, and how it should look. There is no way that one programmer, or even two, can do it all.
This is a prime candidate for a "group project".
Alex has agreed, and has, or will, set up some areas for working on this. I will most certainly be a part of the programming group, and I'm sure Alex will lend his support and experience, but we really need a bunch of people willing to take on various aspects of the program. Consider this an "open source" product add-on/modification to a commercial product. All the rules for group development need to apply!
To start out with, we will need everyone to post their ideas, suggestions, needs, wants, wish lists, essential features and 'like to have' features as much as possible BEFORE planning starts. If you want it to make your coffee in the morning and walk your dog, now is the time to suggest it.
Development will require several groups of people working together, and they are not all programmers. We need people who can take all the comments and suggestions posted in the forum, and create a proposal of what the program really needs to do, what most people want it to do, and what special needs it needs to consider. As new suggestions are posted, those have to be incorporated, so that there is always a "reference doc" for the developers go to, without having to read through the forum.
This "front end" group is an ESSENTIAL part of the process, that filters out the stuff people post, and turns it into a form that the programmers can work with. This doesn't mean the programmers won't read the forums, but it's much better if the programmers stay out of the "consensus" group, at least at first. Now is not the time for trying to decide what can and cannot be done, but rather what everyone WANTS done -- realistic or not.
This "front end" group will have the key job of dealing with the daily posts, taking the new releases and presenting it to the people, and then feeding back the problems. They are the "interface" between the programming group and the user community. These people are very important. They need to know how to read and write, how to use links at least a little, and they have to be able to keep their cool under fire. Their purpose is to prevent the programmers from getting side tracked in all the inevitable tangential "problems" that come up.
Group 2: The Programmers. These are people willing to work in a group, and either help design, or debug, modules or code segments. During development, modularity helps, but once release time comes around, many modules may be combined for performance reasons. This group needs to get along with each other, and be willing to work together to create the interface and rules under which the project develops.
Group 3: The HTML/Graphics/Template group. This group will be responsible
for creating the templates and HTML, as well as default sets of graphics to
be used with the program. This is an important group, since this is what the
"user" will see. This group needs to work closely with the first group, and
the users, to respond to what they need and want. They will have _limited_
need to contact the programmers -- the interface should be well enough defined
that the only communication is if the Group 3 people feel something needs to
be added or changed to make the program better, or if there are of course bugs.
Group 4: The users. You know what you do! You are to be nice to the people
in Groups 1-3 since they are doing this for you, out of no monetary or other
gain.
Hopefully, this is a brief intro to what is needed, and we'll pick up at least a half dozen people who want to be in Group 1 to start dealing with the wish lists for the next week or two.
Early next week, there should be a forum for discussing this, and a means for us to distribute the code.
For now, you can post your comments here, to this thread, but mostly, this thread should be a show of hands with a willingness to participate and what you can or would like to do for the project.
Don't be misled. This is a _BIG_ project. It has to be flexible, and handle a lot of variations. The underlying goal of the project is to create a bunch of flexible routines that can be used to allow people to easily customize how they want their reviews to look and to function. No "hacks". Real, workable, and well designed code, logic flow, and graphical interfaces.
The other benefit of this project is that it will show potential developers and 3rd party developers what it takes to build a plug in! So, everyone should benefit from this.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
The Ratings/Review mod is a really complicated modification, and everyone has a different idea about what it should do, and how it should look. There is no way that one programmer, or even two, can do it all.
This is a prime candidate for a "group project".
Alex has agreed, and has, or will, set up some areas for working on this. I will most certainly be a part of the programming group, and I'm sure Alex will lend his support and experience, but we really need a bunch of people willing to take on various aspects of the program. Consider this an "open source" product add-on/modification to a commercial product. All the rules for group development need to apply!
To start out with, we will need everyone to post their ideas, suggestions, needs, wants, wish lists, essential features and 'like to have' features as much as possible BEFORE planning starts. If you want it to make your coffee in the morning and walk your dog, now is the time to suggest it.
Development will require several groups of people working together, and they are not all programmers. We need people who can take all the comments and suggestions posted in the forum, and create a proposal of what the program really needs to do, what most people want it to do, and what special needs it needs to consider. As new suggestions are posted, those have to be incorporated, so that there is always a "reference doc" for the developers go to, without having to read through the forum.
This "front end" group is an ESSENTIAL part of the process, that filters out the stuff people post, and turns it into a form that the programmers can work with. This doesn't mean the programmers won't read the forums, but it's much better if the programmers stay out of the "consensus" group, at least at first. Now is not the time for trying to decide what can and cannot be done, but rather what everyone WANTS done -- realistic or not.
This "front end" group will have the key job of dealing with the daily posts, taking the new releases and presenting it to the people, and then feeding back the problems. They are the "interface" between the programming group and the user community. These people are very important. They need to know how to read and write, how to use links at least a little, and they have to be able to keep their cool under fire. Their purpose is to prevent the programmers from getting side tracked in all the inevitable tangential "problems" that come up.
Group 2: The Programmers. These are people willing to work in a group, and either help design, or debug, modules or code segments. During development, modularity helps, but once release time comes around, many modules may be combined for performance reasons. This group needs to get along with each other, and be willing to work together to create the interface and rules under which the project develops.
Group 3: The HTML/Graphics/Template group. This group will be responsible
for creating the templates and HTML, as well as default sets of graphics to
be used with the program. This is an important group, since this is what the
"user" will see. This group needs to work closely with the first group, and
the users, to respond to what they need and want. They will have _limited_
need to contact the programmers -- the interface should be well enough defined
that the only communication is if the Group 3 people feel something needs to
be added or changed to make the program better, or if there are of course bugs.
Group 4: The users. You know what you do! You are to be nice to the people
in Groups 1-3 since they are doing this for you, out of no monetary or other
gain.
Hopefully, this is a brief intro to what is needed, and we'll pick up at least a half dozen people who want to be in Group 1 to start dealing with the wish lists for the next week or two.
Early next week, there should be a forum for discussing this, and a means for us to distribute the code.
For now, you can post your comments here, to this thread, but mostly, this thread should be a show of hands with a willingness to participate and what you can or would like to do for the project.
Don't be misled. This is a _BIG_ project. It has to be flexible, and handle a lot of variations. The underlying goal of the project is to create a bunch of flexible routines that can be used to allow people to easily customize how they want their reviews to look and to function. No "hacks". Real, workable, and well designed code, logic flow, and graphical interfaces.
The other benefit of this project is that it will show potential developers and 3rd party developers what it takes to build a plug in! So, everyone should benefit from this.
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Forum:http://LinkSQL.com/forum
Ratings Review Group Project - Pre announcement