I'm wondering if there is a way to get a lot of these stats onto a page automatically - some way to give a project a tag that puts them in the same category - then a page with an argument for that tag that would pull in the project's stats (issue stats, usage stats, maybe some new activity stats).
If we could agree on a good way to do this I would be willing to help champion the feature. Just for the record I totally agree that there should not be regulation, but a way to surface the relevant data better in order for people to 1) understand how to evaluate/compare modules and 2) make it easier for them to do so. On Fri, Dec 4, 2009 at 12:04 PM, Steven Peck <[email protected]> wrote: > Differences occur because > - development happened in a similar time frame. > - developers do not play well with each other. > - developer B has contempt for developer A's code > - and is not courteous in discussions of said codes weakness so does > their own project. > - modules seem the same but use wildly differing methods to achieve > their results. > > > The problem with the 'have the doc team do it' pretends we have > assigned people that will magically carry this out. > - They will install various modules on clean test sites. > - They will have use cases which will allow the evaluation of the > modules in questions > - They assume the module contributor in question is responsive and > that duplication is the result of 'just happened' instead of hostility > between developers. > - The modules are actually similar enough in function to be accurately > compared. > - Users will magically find the module comparison page and it will be > up to date. > > Not really going to happen. > > The best long term suggestion is to have the maintainers clearly > document any differences on their project page (preferably the ones > who are second should do this by default). People (devs) who have a > need for a module and had to evaluate could submit an issue with a > request to have an updated 'difference' description added. Suggested > sample text would probably help. A module maintainer is not > necessarily willing to go download a similar module if theirs already > fills their needs. > > The ones that are not used die out as tracked on the usage page. > > I would suggest a linked article on how to evaluate a project for use > (and suggest how to get description updates) linked to the top of the > Projects page description would be more useful. > > sepeck > > > On Thu, Dec 3, 2009 at 3:36 PM, nan wich <[email protected]> wrote: >> Shai Gluskin wrote: >>> Asking the docs team to write module comparison pieces is a good thing too >> >> NO!!! The comparison pieces should be written by the module developers or >> one of their advanced users. >> >> >> Nancy E. Wichmann, PMP >> >> Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, >> Jr. >> >> > -- ~Jerad Bitner CTO ~ Rapid Waters Development http://rapidwatersdev.com
