Other Software > Developer's Corner

Discussion of CMS suggestions for the DC software directory

<< < (10/17) > >>

Armando:
Thanks for sharing that. I think it's good stuff.

Some complementary thoughts:

- Multiple ways to present the software repository organization : Couldn't all software titles be put in a DB and then, through different filters/queries and sort methods, we could see just what we want in a table/grid like interface ? I'm thinking of Something close to Mantis in terms of functionality, but maybe simpler and nicer (aesthetically).

This would be integrated within the site. It would be easy for the admins to see exactly what needs to be updated, when it was last updated , etc. But maybe is this a terrible idea...  :)

(This wouldn't have to be the only interface : DB data could be formatted differently in other pages where organization would be more static (standard web page))


- Redundant info problem (especially regarding bug tracking and suggestions, I suppose...) : as far as bugs and features suggestions are concerned, I think that all that is needed is a relatively strict way to do things. But since it's  hard to force users to adhere to specific (even simple) rules, it needs to be mostly implemented by the admin's/mod's responsibilities. This doesn't mean that the users shouldn't adhere to a couple rules (e.g. : if you want your bug to be discussed, post in the bug section and tag it as a bug...)

In the InfoQube forum, we've implemented a simple way using the forum and Mantis.

Mantis is the developer's turf, but it can be browsed and issues can be added by anyone there. In reality, only a few users do take the time to do so and it's not a problem.

Anyway, the procedure goes like this :

1- Everything is discussed in the forum.

2- When something is "confirmed" (issue, important feature...), a- it's entered in Mantis with the thread's reference (hyperlink). Mantis isn't a place to discuss things (some discussions take place there, but they are extremely limited and focused)
b- a code is entered in the forum's threads title (so that's obvious that issues have been filed), c-the mantis issue ID is entered in the last post of the thread. (Obviously the mantis Id could just be added to the forums title thread too, so it would be a 2 steps process : a, b)

It looks complicated but it's not. it just means going through all bug reports and suggestions once a week (probably not much more than 10-20), and copy paste info from the forum to Mantis. Some of it could even be scripted (steps a, b). Once that is done, one can forget about the forum, and maybe just update the related threads with info when a serious bug has been fixed. But even that is generally unnecessary.


I think redundancy is probably not as bad as you make it sound.  :) E.g. : as you know accounting systems are based on efficient redundancy, and so is data security, etc. We just need a way to control it so that it doesn't become chaotic. Redundant material used as a "history" for verification purposes needs to be identified as such and then... forget about it, "archive" it (i.e. : let it sink in the forum's abyss).

No idea if this has any value... Sorry if I'm repeating the obvious or wasting your time.  :)

40hz:
I think by going with a moderator/curated type approach you have the best chance of avoiding redundant information spread over several areas of DC.

I'd suggest that any comments/discussions/announcements/bug reports for any software in the directory also be moved over to whatever system (blog?) is being used for the directory. That would gather all relevant info under the actual software titles, which should make the directory a much more focused and relevant resource.

For continuity in the main forum, you could leave the existing structure in place, but include a polite note under each title that says all info and discussions for 'XYZ' have been moved over to the new software directory - and provide links to go there. Might not be a bad idea to lockout new entries being made to the old forum area by people that choose to ignore the notice.

Agree too on the recommendations for using PAD files. They not only provide a standardized info format, they're usable by many other software sites that might also be interested in listing a DC member's creation. That could help gain some additional exposure for DC by making its software collection more visible to search engines by virtue of being listed on other sites.

Just another  :two:

mouser:
Multiple ways to present the software repository organization : Couldn't all software titles be put in a DB and then, through different filters/queries and sort methods, we could see just what we want in a table/grid like interface ? I'm thinking of Something close to Mantis in terms of functionality, but maybe simpler and nicer (aesthetically).
--- End quote ---


I worry this kind of thing would lead us to over-complication.. Let's try to keep this as simple as we possibly can while trying for most of the functionality we think is important. I don't think we have so much software that we need to get crazy with letting people filter and sort entries, etc.  A good compromise might simply be a simple tagging system, and a way to present a page of software with that tag -- then we could create arbitrary collections using tags.

JavaJones:
Much as I dislike it for general CMS use, it seems like Wordpress is actually a legitimate option here. It can for example support the kind of tagging and tag-based presentation that mouser is looking for (and which I agree is needed). Apparently there's also PAD file support, and perhaps even more importantly the person most motivated to work on setting it up has WP experience.

The only thing I'm personally not sure of is how to implement the feedback process and systems. Comments in e.g. WP are more amenable to reviews (e.g. "love this app!"), not so much to bug reporting or tracking. One thought was to have a full sub-forum or even just a single discussion thread for each app in the forum and just link from the app's directory entry. That gives us the full capability of the forums for formatting, discussion, etc. I don't think a formal bug tracker is needed for 90% of the software that will be listed. The rest can use our existing Redmine setup that devs have access to. The question remains though whether a simple "commenting" functionality is enough, or if we should continue to rely on the forums for at least the major part of the actual *discussion*.

- Oshyan

40hz:
Might also not be a bad idea to initiate some dialog with the DC's software authors and get a feel for what they think about all this since it may change how things currently work for them.

With the additional exposure a directory may bring, some of the old "publish & forget" days may be coming to an end. Since most of them do this for free and in their spare time, it may get to be a "job" staying on top of the comments. Especially if a title gets popular due to wider exposure and generates a lot of feedback asking for responses from the author.

 :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page