Re: [Trac] Proposal for Trac
On Thu, Jul 15, 2010 at 5:35 AM, alind sharma wrote: > As I am mainly using trac. Not developing even a single line of it yet. I > can say that having a easy to use gui is not a problem( its good). Trac and > trac hacks are there. Go ahead and start a project on it. If people find it > useful (even the ones who are involved in this thread) will start > contributing. And at the initial stages let it be a hack and not a part of > trac itself, until and unless it stablizes and it requires to be a part of > trac. > As all of the trac is command line (obviously) , So it should be easily > gui-able and need not be a part of trac at all. Not even a plugin. > Just a small request : use some platform independent thing like (qt/tk/wx) > so that in works in linux as well. > http://code.google.com/p/tracker-for-trac/ -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
As I am mainly using trac. Not developing even a single line of it yet. I can say that having a easy to use gui is not a problem( its good). Trac and trac hacks are there. Go ahead and start a project on it. If people find it useful (even the ones who are involved in this thread) will start contributing. And at the initial stages let it be a hack and not a part of trac itself, until and unless it stablizes and it requires to be a part of trac. As all of the trac is command line (obviously) , So it should be easily gui-able and need not be a part of trac at all. Not even a plugin. Just a small request : use some platform independent thing like (qt/tk/wx) so that in works in linux as well. Alind Sharma From: Matthew Caron To: trac-users@googlegroups.com Sent: Wed, 14 July, 2010 11:39:34 PM Subject: Re: [Trac] Proposal for Trac > Let's say, for example, that a lot of the core maintainers read this > thread - your initial post, Correction - it was Todd Worden's initial post. You were agreeing with him. Apologies for the lack of historical accuracy. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
Let's say, for example, that a lot of the core maintainers read this thread - your initial post, Correction - it was Todd Worden's initial post. You were agreeing with him. Apologies for the lack of historical accuracy. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
It's so damn annoying that I've to spend my rare time having to hack nearly every simple plugin to get it work I agree, but this is why I contribute back my changes. If everyone does this, eventually it all just works(tm), right? Also, plugins not working out of the box has nothing to do with packaging up trac with an installer, or better documenting how to install it. and to set up many repeating jobs by hand How so? I do not find myself doing this at all. Your statement is very unbalanced - if I understood you correctly, everybody who is no experienced Python programmer even doesn't have the right to use Trac - because trac is only for cool programmers. That was not my intended message. What I meant was that you need to *learn* things like how your systems go together in order to properly administer them. Many experienced Unix admins aren't Python programmers I wasn't either, until I started using Trac. It is still my least favorite language. and even don't have the time to learn it - only because 1 of their tools lacks convenience functions like an installer! This argument is a paper tiger. You don't need to learn python to run the existing installer. You can just read the INSTALL file and follow the (well documented) instructions. And your time estimations fail in reality: I'm using Trac (and programming and bugfixing plugins for it) for 3 years now - but a new Trac (especially a version jump like 0.10 to 0.11) took me nearly a week, until all of my plugins worked (often this isn't the case, due to version incompatibilities). I've only been doing the 0.11.x upgrades, so your point may be valid. AND: Many companies try tools like Redmine etc. and even don't know about Trac and even if they do - it's (even for a hardcore user like me) hard to tell them, But why do you care? If they're using Redmine, and they're happy doing so, then where is the issue there? If they want a demo, isn't that what the t.e.o site is for? what Trac can do and how to set it up (no, they aren't noobs, yes - there are many IT professionals who aren't cool Python hackers). Meanwhile, there are quite a few people who regard installing Trac as positively trivial - the hardest part being the *optional* Apache installation. So, if what we're arguing is "is Trac too difficult to set up", I'd argue "No. Because, in my personal experience, everyone who I've talked to who has had to set up Trac has found it well documented and trivial". I agree with your statement that opening the project for simple users (noobs) will increase the amount of support drastically. But be honest: That can be influenced and solved. And: Which script kiddy needs Trac? I'd argue that a very large portion of what constitutes IT these days are at that level. Heck, Microsoft made a whole marketing push out of it back in the NT 4 days - why hire expensive Unix experts when Windows is easy so the labor is cheap! And: The lack of documentation is a typical developer problem - why do argue against documentation? I'm not. However, the documentation *I* would like to see written is *not* yet another "this is how you install Trac" howto (because there are quite a pile of them out there, where the INSTALL file is really quite sufficient), but rather extensive documentation of all the interfaces, APIs, etc. Please: Skip telling me "sources are the best documentation" - thats a reason to get fired in my job. I don't recall ever saying that. Indeed, that's what I use Trac for the most - documenting how all the bits work. PS: You understand to demotivate people who want to contribute! Good work! So any criticism of a proposal is demotivational? I thought the discussion would be good for focusing our efforts as a community, as to *where* exactly we wanted to spend our time. To put it another way: Let's say, for example, that a lot of the core maintainers read this thread - your initial post, several folks agreeing with you, and they said "well, it seems like everyone agrees with this fellow, maybe we should spend some time on that". Meanwhile, there's a bunch of other people who didn't want to criticize the idea who really don't care. However, they didn't speak up when they had the chance, and engage in the discussion, so they really can't complain, can they? -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
On Wed, Jul 14, 2010 at 10:37 AM, Christian Dähn wrote: > Hi, > :o) > And: The lack of documentation is a typical developer problem - > why do argue against documentation? > IMHO , I like well written and comprehensive (and example-driven) documentation of software projects . Nonetheless, I have so many problems to solve and ideas to implement using Trac (and my lifetime limit is about ... 120 yo ?) that the time I'd dedicate to over-document plugins , I prefer to spend it in developing new functionalities ... ;o) > Please: Skip telling me "sources are the best documentation" - Yes, "sources are the best documentation" , but not the only one ... > thats > a reason to get fired in my job. > ... I suppose that part of the salary covers that (whereas I have no salary to develop Trac plugins -and living is sometimes an expensive experience AFAICT-) > PS: You understand to demotivate people who want to contribute! Good work! > Hope this won't start a flamewar . I suppose that nobody wants to demotivate anybody ... -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
Hi, oh boy - I'm a not soo unskilled linux admin and python & C++ developer - but: It's so damn annoying that I've to spend my rare time having to hack nearly every simple plugin to get it work and to set up many repeating jobs by hand - as developers we MUST be lazy and thus there should be a (half) automated solution to do simple repeating tasks by automatisms. Your statement is very unbalanced - if I understood you correctly, everybody who is no experienced Python programmer even doesn't have the right to use Trac - because trac is only for cool programmers. Many experienced Unix admins aren't Python programmers and even don't have the time to learn it - only because 1 of their tools lacks convenience functions like an installer! And your time estimations fail in reality: I'm using Trac (and programming and bugfixing plugins for it) for 3 years now - but a new Trac (especially a version jump like 0.10 to 0.11) took me nearly a week, until all of my plugins worked (often this isn't the case, due to version incompatibilities). AND: Many companies try tools like Redmine etc. and even don't know about Trac and even if they do - it's (even for a hardcore user like me) hard to tell them, what Trac can do and how to set it up (no, they aren't noobs, yes - there are many IT professionals who aren't cool Python hackers). I agree with your statement that opening the project for simple users (noobs) will increase the amount of support drastically. But be honest: That can be influenced and solved. And: Which script kiddy needs Trac? And: The lack of documentation is a typical developer problem - why do argue against documentation? Please: Skip telling me "sources are the best documentation" - thats a reason to get fired in my job. ciao, Chris PS: You understand to demotivate people who want to contribute! Good work! -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
Even if I agree 90% with you, in this case, the only thing I'd like to point out is that sometimes it's useful to have the possibility of building up-to-date Trac installers containing a given set of plugins as well as initial environment configuration (which might be a simple apt-get-infected bash script , but AFAICS the number of Trac plugins packaged for Debian is still scarce , and this approach doesn't work with other systems :( ... ) Fair point. However, I would argue that Trac is one of those "so absurdly hackable" systems that there is no point in installing it from a pre-done package, because you're going to want to change *something*. Plus, the existing installation script (as documented in INSTALL, and basically boils down to: python ./setup.py install), is so trivially easy that I don't really care about my distro's premade packages. I tend to only use them for the general python library dependencies. I take it a step further, cloning the repo with git-svn and maintaining my own local branch with site-specific customizations. Anything generally useful is submitted back as a patch (though I tend to have more fixes on plugins than the core code, it mainly just works(tm)). As new versions come out, they are merged into this local branch and pushed to testing. Once they pass testing, I merge them into production and deploy there. In general, upgrading to a new version of Trac (merge, test, etc.) takes about 2 days, so it's not like it's a big deal. If I didn't do the due diligence derived from too many years working at a 24/7/365 uptime web business, it would only take a couple of hours... I do think that admin skills and knowledge about the system are still necessary , but I also think that e.g. iniadmin plugin is cool (with respect to editing trac.ini ;o). That's a different level of administration than what I'm talking about (development and deployment vs. day to day operations), so I totally agree with you. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
Hi ! On Wed, Jul 14, 2010 at 7:42 AM, Matthew Caron wrote: > Warning: This is personal opinion, and I'm going to be climbing up on my > soapbox here for a bit. If a bunch of folks want to work on the parent's > project, don't let me stop you, but I feel that a counter point here might > be useful. > [] Even if I agree 90% with you, in this case, the only thing I'd like to point out is that sometimes it's useful to have the possibility of building up-to-date Trac installers containing a given set of plugins as well as initial environment configuration (which might be a simple apt-get-infected bash script , but AFAICS the number of Trac plugins packaged for Debian is still scarce , and this approach doesn't work with other systems :( ... ) I do think that admin skills and knowledge about the system are still necessary , but I also think that e.g. iniadmin plugin is cool (with respect to editing trac.ini ;o). PS: I'm probably hijacking the purpose of this thread , but ... I just said so ! -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
Warning: This is personal opinion, and I'm going to be climbing up on my soapbox here for a bit. If a bunch of folks want to work on the parent's project, don't let me stop you, but I feel that a counter point here might be useful. Hi, I agree: a) public relation isn't a strength of Trac ;-) Nor should it be. I want Trac to be awesome. It is. PR doesn't help with that. Sure, it helps more people know about Trac's awesomeness, but viral advertising (word of mouth, blog posts, podcasts, etc.) is free. Further, the last thing I want is this list being invaded by a bunch of clueless n00bs who need to go RTFM. Indeed, I remember listening to someone from a F/OSS project (inkscape, I think, but I could be wrong), who was talking about how they tried to make it easier to use and came out with a Windows installer, and then all of a sudden they get deluged with people who have zero clue. The estimate I heard was that it set their project back a year because they had to deal with the pile of totally useless bug reports, endless basic questions, etc. b) it's really hard to explain business people why to introduce Trac I don't understand why you're doing this. It's free. Find a box, set it up, start using it. Share it with other users, and I think you'll irally infect your organization. Productivity goes up, and folks are happy about it. Alternatively, lot of arguments can be made about improved productivity, but unless you're comparing it to no process at all, the numbers are essentially meaningless anyway. In the end, I find it comes down to someone installing a bunch of them, setting them up, letting people beat on them, and doing a comparative analysis of a whole pile of very soft criteria. However, the only real test is running it as your production process for 3-6 months. That said, Trac may not always win. If what you have meets your needs, then why bother convincing people to move to Trac? This is a pragmatic decision about worker efficiency, not a religious war. c) the first steps to install and configure aren't documented for non-developers Why should non-developers be installing it anyway? This is a job for IT. (Defined as "developers who serve internal customers rather than external customers"). If this is not the case in your organization, than your organization is broken, and you have bigger problems. d) running and maintaining Trac often requires developer or command line skills Which the people maintaining it should have, or they should learn them. Essentially, your argument boils down to this: Trac is too hard because it requires people to learn skills. I look at it as: These are skills that people maintaining Trac should have. If they don't, they should learn them. If they are unwilling to learn them, then perhaps they should find another line of work, because this is what is required for proper system administration. You need to understand how the system *actually works*. better: how to install Trac _WITHOUT_ going to the command line (gui based installers for Linux + Windows). On Linux, you can always just get the premade package for Trac from your repository. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
Hi, >... starting place with advertising for Trac and a very simple install HowTo - >better: how to install Trac _WITHOUT_ going to the command line (gui based >installers for Linux + Windows). > >=> http://bitnami.org/stack/trac That's near to what I thought of - but: a) nearly all bundles are built more than a year ago b) there are no important plugins (like AccountManager), the subversion and a database integrated already But the BitRock installer is exactly what I thought of - so we just have to build a good installer with automatic installation of the prerequisites like Subversion, Python and "eazy_install" and a working default config filled out by the installer. That part is solvable. ciao, Chris -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Proposal for Trac
On 7/14/2010 12:49 AM, Christian Dähn wrote: Hi, I agree: a) public relation isn't a strength of Trac ;-) b) it's really hard to explain business people why to introduce Trac c) the first steps to install and configure aren't documented for non-developers d) running and maintaining Trac often requires developer or command line skills So there could be a big positive effect, if someone starts creating a simple to understand starting place with advertising for Trac and a very simple install HowTo - better: how to install Trac _WITHOUT_ going to the command line (gui based installers for Linux + Windows). => http://bitnami.org/stack/trac -- Christian -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
RE: [Trac] Proposal for Trac
Hi, I agree: a) public relation isn't a strength of Trac ;-) b) it's really hard to explain business people why to introduce Trac c) the first steps to install and configure aren't documented for non-developers d) running and maintaining Trac often requires developer or command line skills So there could be a big positive effect, if someone starts creating a simple to understand starting place with advertising for Trac and a very simple install HowTo - better: how to install Trac _WITHOUT_ going to the command line (gui based installers for Linux + Windows). Currently I've really less time, but I'm interested into contributing - and have some experiences with user level documentation. So: I would try to start a simple docu page for Trac - this won't be a work done in a few days - and can't be done alone. As soons as I got a first page online, I'll inform and invent you to help me :-) ...help means: wishes and questions for the page and - very appreciated - maybe help writing some entries ;-) ciao, Chris -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
RE: RE: [Trac] Proposal for Trac
Mayhaps you sent this to the wrong place? --Noah From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Todd Worden Sent: Friday, July 02, 2010 5:19 PM To: trac-users@googlegroups.com Subject: Re: RE: [Trac] Proposal for Trac Thanks... does anyone else second the motion? On Jul 2, 2010 7:55 PM, "Mikael Relbe" wrote: Hi Todd and all Trac users I am also involved in not one, but many, organisations that would benefit from the use of Trac (and Subversion). The "problem" with these tools is the lack of a "sales organisation" making efforts in marketing them towards presumptive customers/organisations. Trac stands by itself, laying there to be discovered by committed users like us. It's quite hard work to first understand *how* to use the tools effectively (that's an art I think, the core team at Edgewall.org are great artists and source of inspiration), it's then even harder to gain insights to the level that one can recommend the usage of these tools to industrial organisations, who demands high-level services from their suppliers. But since these tools do not have any supplier, you are facing a tremendous challenge... Therefore, I would be very interested in your findings, I think many here would. I don't want to see a debate either, that's not interesting, but official business case examples would be of great help as references, to put strengths to the arguments that Trac is a very serious and capable tool. I meet alot of senior management, decision making, people, and it is (currently) quite hard to explain to them how it can be that an open source, freeware, project control tool can be worth investing in. Even if the tool is free, assistance is needed in training and mentoring, which costs money. The decision to use these tools to handle critical business/project information, and become dependent on their existance and evolvement, is a very hard decision. From a career point of view, a manager can never be accused of making a bad decision if he/she decides to go with a high-cost tool provided by a well-known supplier having armies of sales personnel, training and support staffs etc. The decision to choose Trac (and Subversion) can scare away the slightest career-aware manager operating in a large organisation... (I'm exaggerating just to make a point, I've seen the opposite too.) If it's possible to collect arguments for using Trac, and references, without bashing other alternatives, I would be very happy to read about that here! Best regards Mikael Relbe _ From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Todd Worden Sent: Saturday, July 03, 2010 12:11 AM To: trac-users@googlegroups.com Subject: [Trac] Proposal for Trac > Hi group, > > I am writing a proposal for an large organization I am contracting with primarily as... -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com <mailto:trac-users%2bunsubscr...@googlegroups.com> . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com <mailto:trac-users%2bunsubscr...@googlegroups.com> . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
RE: [Trac] Proposal for Trac
Just to be clear, there isn't really a "edgewall.org" team. Trac (and Genshi, Bitten, Babel)are developed by a set of volunteer contributors. FOSS projects that aren't of the scale of things like Firefox don't have a budget or company behind them. The documentation is definitely an area where Trac could use improvement, but the only way that will happen is if people like yourself submit patches. --Noah From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Mikael Relbe Sent: Friday, July 02, 2010 4:55 PM To: trac-users@googlegroups.com Subject: RE: [Trac] Proposal for Trac Hi Todd and all Trac users I am also involved in not one, but many, organisations that would benefit from the use of Trac (and Subversion). The "problem" with these tools is the lack of a "sales organisation" making efforts in marketing them towards presumptive customers/organisations. Trac stands by itself, laying there to be discovered by committed users like us. It's quite hard work to first understand *how* to use the tools effectively (that's an art I think, the core team at Edgewall.org are great artists and source of inspiration), it's then even harder to gain insights to the level that one can recommend the usage of these tools to industrial organisations, who demands high-level services from their suppliers. But since these tools do not have any supplier, you are facing a tremendous challenge... Therefore, I would be very interested in your findings, I think many here would. I don't want to see a debate either, that's not interesting, but official business case examples would be of great help as references, to put strengths to the arguments that Trac is a very serious and capable tool. I meet alot of senior management, decision making, people, and it is (currently) quite hard to explain to them how it can be that an open source, freeware, project control tool can be worth investing in. Even if the tool is free, assistance is needed in training and mentoring, which costs money. The decision to use these tools to handle critical business/project information, and become dependent on their existance and evolvement, is a very hard decision. From a career point of view, a manager can never be accused of making a bad decision if he/she decides to go with a high-cost tool provided by a well-known supplier having armies of sales personnel, training and support staffs etc. The decision to choose Trac (and Subversion) can scare away the slightest career-aware manager operating in a large organisation... (I'm exaggerating just to make a point, I've seen the opposite too.) If it's possible to collect arguments for using Trac, and references, without bashing other alternatives, I would be very happy to read about that here! Best regards Mikael Relbe _ From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Todd Worden Sent: Saturday, July 03, 2010 12:11 AM To: trac-users@googlegroups.com Subject: [Trac] Proposal for Trac Hi group, I am writing a proposal for an large organization I am contracting with primarily as a SharePoint developer. This organization is substantially weighted in proprietary technologies centered around Microsoft. While I enjoy development with M$ tools, it is my experience and professional opinion Trac + Subversion + CCnet can't be beat. Along with other philosophical views, I proposing the adoption of these technologies over an opposing proposal for Team Foundation Server. I've read through blog comparisons between the two, and would prefer this post not evolve into a debate. Rather, I am looking for guidance in the form of verbiage, business advocacy, and argumentative leverage in support of Track, et. Al. Also, I have started a rough draft proposal supporting my case and would like to post it, only if this group feels this place is an appropriate forum for my request. Of course I will sanitize it to preclude any possibility for ethics breach, but I think I'm a far cry away from the likelyhood of that. Awaiting you're feedback. Gratefully, ISZ -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to
Re: RE: [Trac] Proposal for Trac
Thanks... does anyone else second the motion? On Jul 2, 2010 7:55 PM, "Mikael Relbe" wrote: Hi Todd and all Trac users I am also involved in not one, but many, organisations that would benefit from the use of Trac (and Subversion). The "problem" with these tools is the lack of a "sales organisation" making efforts in marketing them towards presumptive customers/organisations. Trac stands by itself, laying there to be discovered by committed users like us. It's quite hard work to first understand *how* to use the tools effectively (that's an art I think, the core team at Edgewall.org are great artists and source of inspiration), it's then even harder to gain insights to the level that one can recommend the usage of these tools to industrial organisations, who demands high-level services from their suppliers. But since these tools do not have any supplier, you are facing a tremendous challenge... Therefore, I would be very interested in your findings, I think many here would. I don't want to see a debate either, that's not interesting, but official business case examples would be of great help as references, to put strengths to the arguments that Trac is a very serious and capable tool. I meet alot of senior management, decision making, people, and it is (currently) quite hard to explain to them how it can be that an open source, freeware, project control tool can be worth investing in. Even if the tool is free, assistance is needed in training and mentoring, which costs money. The decision to use these tools to handle critical business/project information, and become dependent on their existance and evolvement, is a very hard decision. From a career point of view, a manager can never be accused of making a bad decision if he/she decides to go with a high-cost tool provided by a well-known supplier having armies of sales personnel, training and support staffs etc. The decision to choose Trac (and Subversion) can scare away the slightest career-aware manager operating in a large organisation... (I'm exaggerating just to make a point, I've seen the opposite too.) If it's possible to collect arguments for using Trac, and references, without bashing other alternatives, I would be very happy to read about that here! Best regards Mikael Relbe -- *From:* trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] *On Behalf Of *Todd Worden *Sent:* Saturday, July 03, 2010 12:11 AM *To:* trac-users@googlegroups.com *Subject:* [Trac] Proposal for Trac > Hi group, > > I am writing a proposal for an large organization I am contracting with primarily as... -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
RE: [Trac] Proposal for Trac
Hi Todd and all Trac users I am also involved in not one, but many, organisations that would benefit from the use of Trac (and Subversion). The "problem" with these tools is the lack of a "sales organisation" making efforts in marketing them towards presumptive customers/organisations. Trac stands by itself, laying there to be discovered by committed users like us. It's quite hard work to first understand *how* to use the tools effectively (that's an art I think, the core team at Edgewall.org are great artists and source of inspiration), it's then even harder to gain insights to the level that one can recommend the usage of these tools to industrial organisations, who demands high-level services from their suppliers. But since these tools do not have any supplier, you are facing a tremendous challenge... Therefore, I would be very interested in your findings, I think many here would. I don't want to see a debate either, that's not interesting, but official business case examples would be of great help as references, to put strengths to the arguments that Trac is a very serious and capable tool. I meet alot of senior management, decision making, people, and it is (currently) quite hard to explain to them how it can be that an open source, freeware, project control tool can be worth investing in. Even if the tool is free, assistance is needed in training and mentoring, which costs money. The decision to use these tools to handle critical business/project information, and become dependent on their existance and evolvement, is a very hard decision. From a career point of view, a manager can never be accused of making a bad decision if he/she decides to go with a high-cost tool provided by a well-known supplier having armies of sales personnel, training and support staffs etc. The decision to choose Trac (and Subversion) can scare away the slightest career-aware manager operating in a large organisation... (I'm exaggerating just to make a point, I've seen the opposite too.) If it's possible to collect arguments for using Trac, and references, without bashing other alternatives, I would be very happy to read about that here! Best regards Mikael Relbe _ From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Todd Worden Sent: Saturday, July 03, 2010 12:11 AM To: trac-users@googlegroups.com Subject: [Trac] Proposal for Trac Hi group, I am writing a proposal for an large organization I am contracting with primarily as a SharePoint developer. This organization is substantially weighted in proprietary technologies centered around Microsoft. While I enjoy development with M$ tools, it is my experience and professional opinion Trac + Subversion + CCnet can't be beat. Along with other philosophical views, I proposing the adoption of these technologies over an opposing proposal for Team Foundation Server. I've read through blog comparisons between the two, and would prefer this post not evolve into a debate. Rather, I am looking for guidance in the form of verbiage, business advocacy, and argumentative leverage in support of Track, et. Al. Also, I have started a rough draft proposal supporting my case and would like to post it, only if this group feels this place is an appropriate forum for my request. Of course I will sanitize it to preclude any possibility for ethics breach, but I think I'm a far cry away from the likelyhood of that. Awaiting you're feedback. Gratefully, ISZ -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Proposal for Trac
Hi group, I am writing a proposal for an large organization I am contracting with primarily as a SharePoint developer. This organization is substantially weighted in proprietary technologies centered around Microsoft. While I enjoy development with M$ tools, it is my experience and professional opinion Trac + Subversion + CCnet can't be beat. Along with other philosophical views, I proposing the adoption of these technologies over an opposing proposal for Team Foundation Server. I've read through blog comparisons between the two, and would prefer this post not evolve into a debate. Rather, I am looking for guidance in the form of verbiage, business advocacy, and argumentative leverage in support of Track, et. Al. Also, I have started a rough draft proposal supporting my case and would like to post it, only if this group feels this place is an appropriate forum for my request. Of course I will sanitize it to preclude any possibility for ethics breach, but I think I'm a far cry away from the likelyhood of that. Awaiting you're feedback. Gratefully, ISZ -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
