On Tuesday 01 July 2003 07:39 am, you wrote:
> Michael S. Zick wrote:
> >On Monday 30 June 2003 07:01 pm, Tex wrote:
> >>Do you think it might be a good idea to put up a wiki for the developers?
> >>as a place to collaboratively sort out priorities, problems, roles,
> >> design principles and goals? As a starting point for an dev/api
> >> documentation?
> >>Maybe it might even make sense for the users too.
> >Very good suggestion.
> >It makes a lot of sense for developers also.
> >Nearly everything mentioned in this thread could be
> >dealt with in a (tiki-)wiki.
> >Doesn't it make sense that the people who write it
> >should also use it?
> I wholeheartedly concur. Its come up a couple times on this list in the
> past month, but I think it would be a really good idea to use Tiki as a
> collaborative development environment. Luis was afraid, I think, that
> setting up another infrastructure would consume too many people that
> could be contributing directly to the development of the project
> though. I've been thinking about this, and think that maybe there are
> enough people now that setting up a 3 member "Infrastructure Team" might
> not be a bad idea. All 3 people would be responsible for setting up and
> maintaining the dev and demo site infrastructures and prodding everyone
> else to use it. Having more than 1 person will help make sure that even
> when someone gets busy, the environment is still being fed and
> watered... my 2 cents anyway.
Shouldn't be hard - you don't need a "How to set up for XXXX use"
You have all the knowledge of the authors available.
Put up anything...
Somebody will see the feature they added and point out
how it should be optioned to work for this purpose.
> Part of my reason for this is selfish, because I need just this sort of
> thing at my work, and am in charge of getting together some process and
> planning tools to help manage our development processes. I think Tiki
> would bring a lot to the table, but now I just need to find the time to
> get it set up. I think that if the dev group used and maintained a tiki
> for all dev work, discussion, bugs, feature voting, etc that we'd also
> learn a lot about the shortcomings and bugs that we would find in the
> day to day, more long term use.
Nothing wrong with that - when it gets close to what you need, dump
the preference and option settings then import them into yours.
> Also because I think that SourceForge, for all its goodness and features
> for the OSS community, is still a pretty immature product as far as the
> day to day software development project management goes. The trackers
> are just a hair above pointless in my book. :)
During the early days of SF, development was rapid - but the "SourceForge
Idea" drew should a large number of users - they had to pick some point
at which to stablize the user interaction.
Instead of API of it as a UPI.
> Which reminds me: All, I apologize for not enacting the bug categories
> and getting RFE categories and individual RFE's sorted out. Its annual
> review time here at work, and I have to write and conduct reviews for 20
> odd software developers, so my time recently has been limited. I'm very
> much shooting for this fourth of july weekend to try to get stuff at
> least set up so that we can sort everything out, but it may not happen.
> Trying my best. (would still like some feedback on my email previously
> about the RFE's and what we should use the "groups" for on them...)
> man, I hate it when I start out a short email, and it turns into war and
> peace... sorry. :)
No matter. Your comments are all constructive.
Not any worse than throwing fuel on a pile of dry leaves only
to learn they where covering a smoldering fire.
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> Tikiwiki-devel mailing list