OpenURU.org Resources & Tools

[Dot]

I'd go for bugs.openuru.org as well.

[ametist]

IMHO : bugs.openuru.org

[Grogyan]

IMHO : bugs.openuru.org

I'll third that

[JWPlatt]

Ok, ok, I'm convinced already.

But what if the system is also used for issue resolution and such? Make a different subdomain go to the same place? e.g. support.OpenURU.org?

(By the way, chat.OpenURU.org now redirects to rel.to/openuru_irc, the OpenURU.org irc chat link).

[Marten]

All bugs are features, ergo, all features are bugs.

[Dot]

To me it makes sense to use a subdomain such as 'support.openuru.org' for people having general problems with OSMO. They wouldn't necessarily think it was a bug causing the problem, and 'support' sounds friendlier!

This would also match up with the subdomain of the old MOUL ticketing system.

Keep bugs.openuru.org for the active bug testers.

Though, having said that, it might be sensible to wait a bit and see what issues crop up before creating another subdomain.

[rarified]

For the moment, why not point support.openuru.org (virtual host) to a page hierarchy on the Wiki for self-help? That can include links to the bugtracker, mail list, suggested forum topics, project-specific resources, etc.

[JWPlatt]

For the moment, why not point support.openuru.org (virtual host) to a page hierarchy on the Wiki for self-help? That can include links to the bugtracker, mail list, suggested forum topics, project-specific resources, etc.

Nice. That's using the noggin (and the resources).

By the way, next up for resource & tool discussion is project management and content management systems for project or inter-project use. Like OpenURU.org subdomain websites, or as an alternative to them, the CMS would presumably be for public display. Perhaps some mix of public and secure with project management.

But these things are only going to happen if they are useful. So let me know about that too. We don't need useless complexity.

I'll give you a starting point:

I've been looking at Joomla and dotProject.

http://www.joomla.org/ (Content Management)
http://www.dotproject.net/ (Project Management)

There are some commonalities in these packages with the forums, the wiki and the Mantis bug tracker. It would be nice to not waste the features of one package or another, or cause confusion about which is better for project tasks. I certainly don't want the same information needing to be stored at multiple places. But choice is not always a bad thing.

[Dot]

GoMa uses Joomla for the webpages. I quite like it (better than Wiki).

[Marten]

/thumbsdown for dotproject.

Used it for a while at my workplace. For simple projects, it is overkill. For projects of sufficient complexity to justify using a tool like dotproject, one should just spend the money to get a better tool. Maybe someone else here has had a better experience with it, but I found it clunky. Things I found aggravating (based on 2.0.4):

• [+]/[-] boxes to the left of projects did not follow the expected standard. Instead of closing/expanding tasks under the project, these buttons hide and reveal all other projects other than the one selected. Curiously, the exact same symbol, when associated with a TASK rather than a PROJECT, expanded and closed a subtask tree exactly as one would expect.
• Although I had editing privs for a task on a project, selecting that task would present the task in a non-editable format. I would then have to click "Edit this task" to get to the editor.
• Task Editing uses a series of 4 tabs to segregate information such as "Details", "Dates", "Dependencies", and "Human Resources." Except for "Dependencies," none of these tabs is so complex that it really needed its own tab.
• Despite the categorization into 4 tabs, "Task Parent" and "Move this task to another project" are on the Details tab, rather than the Dependencies tab.
• There is a "Flat" option that eliminates the tabs, but then all categories are lumped onto one page - when Dependencies really does deserve its own tab.
• Many fields require a person to scroll through a list to select the desired items. For example "Human Resources" can only be assigned by picking names out of a list and then clicking an arrow to assign the persons to the project. There is no way to begin typing in the name, so that the system might automatically narrow down to the desired matching items. As a result, if there are many items on a list (many people working on a project), this can quickly become a pain.

I don't see a real comparison between Joomla and a Wiki. (What follows is how I perceive things, and this is not my area of expertise - someone like Sophia (who is designing a new GoMe site) would be better at describing the differences, and the strengths and weaknesses, of these. I do know the GoMe is implementing both a CMS and a Wiki.)

To me, Joomla (or any other "web content management system") is about aesthetics - how content is arranged for display. CMS lets you make your content look like a newspaper.

And to me, a Wiki is about making content community-editable; there is a hierarchy and organization to the content, but that is consistently in an outline form; your content looks more like a research paper.