using Trac for non-software projects?
maphew
Is anybody using Trac for projects which *aren't* about software
development? If yes would you care to share your successes or
failures? or suggest another open source wiki / issue / project
tracking application to look at?
thanks!
-matt
Miguel Angel Laguna
We are using trac to manage implementation proccess of a big project.
We have 2-3 or more issues every day and our provider is continously
releasing patchs and SQL scripts.
We use trac to manage issues and patchs. We are very happy with trac.
We are thinking of using trac to other projects, but we are waiting
for a better multiproject support.
Regards.
2007/3/8, maphew <map...@gmail.com>:
--
Miguel A. Laguna
"La vida es aquello que te sucede, mientras te empeñas en cumplir tus
expectativas"
Andrew Nelson
other solutions such at RT, Double Choco Latte and did not like their
feature sets. For us the tight integration of a ticket and wiki system
is what tipped the scales. I am eagerly awaiting the new ticket
revisions in 0.11 for both clients.
Overall we have been quite satisfied with the functionality and
flexibility of Trac. When time allows we will be setting up another
Trac server of our own internal issue tracking purposes.
-Andrew
Aaron D. Marasco
On Thu, March 8, 2007 02:08, maphew wrote:
> Is anybody using Trac for projects which *aren't* about software
> development? If yes would you care to share your successes or
> failures?
Why don't you be more specific? What do you need?
I use it daily for hardware development. We have schematic and other
binary files kept using locks. The VHDL might as well be software as far
as trac/svn is concerned; all the diff utilities work fine and the
enscript system does all the syntax highlighting in changesets and
snippets on wiki pages.
When a board is RFQd it gets svn tagged. When a layout has been signed off
on and will be fabbed, another tag. After that point, any white wire
changes needed are kept in tickets and the milestone is the next hardware
revision.
The only restriction we have on users is that they must check out 'trunk'
to c:\proj\<svn_proj_name>\ because some of our tools are retarded and
have binary project files with hardcoded paths. This gets around that.
- Aaron
--
Sent using a web interface, so I am sending this instead of working.
acro
module.
The Wiki as a knowledge base and for general info about the company
and the departments.
I installed the Discussion plug-in to support forums. The Download
plug-in as a repository for files. In the ticket module, the
"components" are the departments. Quarter of year are "Milestones".
We have some problems with permissions, groups and reports but besides
that I have to say that Trac is helping a lot.
Regards,
maphew
> > Is anybody using Trac for projects which *aren't* about software
> > development? If yes would you care to share your successes or
> > failures?
>
> Why don't you be more specific? What do you need?
A fair question, what do we need? It's a bit hazy, which is probably
why I'm having a hard time finding something, but the general outline
is:
- help desk style requests: "I need X installed on a laptop before I
go in the field this summer", "Dooamahickey gives this error when I
attempt to open ..."; problem reported by..., assigned to...; resolved
at ...; etc.
- knowledge base docs: "How to install X", "Standards and Procedures
for..."; docs needed for...; this doc is [complete | in progress | a
mess| ...];
- Product Catalogue, specifically maps: "Env.059 - Finlayson Caribou
Herd Survey, March 2007; 1:00,000 scale, base topography + survey
polygons; corner coordinates: X,Y - X,Y; client: John Smith; etc.;
[thumbnail]; [pdf]"
- Project tracking: "Env-dat.028 - Acquire base data for ...., build
seamless mosaick, put in shared departmental repository"; initiated
by..., assigned to...; due date; finished when ...; results at ...;
working data at...; supporting scripts and documents...; parent/child
projects; project is [done | partial | abandoned | hibernating]; etc.
Many projects result in maps (Product Catalog) and system
documentation (Knowledge Base); Many maps result in one or more
projects. It can be important to know the relationships. For instance
when a new dataset is updated many downstream maps will need to be re-
issued, and likely some docs too.
It may be that we will, probably will, need more than application to
track these different tasks and items. It sure would be nice if they
could be accessible from a unified starting point, and globally
searchable.
maphew
-matt