[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Debian-sf-devel] Future functionality questions...

From: Eric D Nielsen
Subject: Re: [Debian-sf-devel] Future functionality questions...
Date: Thu, 27 Dec 2001 13:54:43 -0500

> That aside I love your ideas especially about the security. I have no idea 
> how foundries would be used in my organization. My planned changes to SF 
> include better task tracking (borrowing a lot of ideas from TUTOS which has 
> spectacular project tracking), and a more usable front page (which lists 
> departments or projects or something).   It will take some time I am sure 
> before I get to any serious changes because I have to do a lot of testing 
> first (I am using the new 2.6 codebase).

Here's a use case description of the improved foundry system might be used
and how it might be useful to you.  (I agree that task tracking is something 
I would love to see handled better, too! )

You set up the foundry system to have three Foundry Classifications:
Tools, General Guidelines, and Departments.  Tools of course would contain
the assorted program languange, database specific  foundries like SF has,
This section probably wouldn't have many sub-foundries the site admin
would probably still be approving new foundries in the normal method, but
menu updating would be taken care of for you.  General Guidelines is a section
that could contain various howtos and company specific rules/guidelines/etc.
(Yes I'm envisioning some foundries possibly being empty of projects but
being useful as document repositories/libraries)  These foundries could be
under the control of various branches of the organization's IS department
giving the the authority to break out sub foundries(repositories) as they see
fit.  Finally the department Classification group allows you to give each 
department its own space to play in.  Each Department has its own foundry where
they can stick their own department spcific docuements and projects.  If
a department has a major project with sub-projects that can create the
major project as foundry and place the sub pieces under it, etc.  Furthermore
because they are the foundry admins the have the authority to add/remove
the sub-foundries as they see fit (Of course at present you still have to
be a site admin to approve the new project/foundry, we may look into some
ways of delegating this responsibility....).  This gives the departmentes some
flexibility to structure their SF space to suit their needs/ organization 
without bogging down the site admin in endless foundry approval/creation.

Of course SF supports a project being a member of multiple foundries so
cross departmental projects are not a problem and as both projects and
foundries inherit from groups, foundries may belong to multiple parent 
foundries if need.  (Ie if you wanted to have some sort of cross-cutting
team from multiple departments have its own foundry or something)

(We aren't doing this exactly, our user base isn't arranged in departments, but
around function "nodes" of an interactiing system, each node typically
is a suite of cooperating large programs, most of our projects are small 
enhacments to these large programs)

> In short. I for one would love your changes. I do have a question though. 
> Will those changes be applied through apt-get? Will the package maintain my 
> data (this applies to all upgrades of sf from now on I guess).

I will be submitting my bundles as they are finished/tested as patches against
the current debian-sf code tree.  If they are accepted by the Roland then I
would assume they would be folded into the next release version so you 
would get the changes the same way you get any other upgrade/update.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]