[Trac] Re: how is trac SUPPOSED to be used?
On Wed, Oct 8, 2008 at 10:45 AM, Robert C Corsaro <[EMAIL PROTECTED]> wrote: > > Dimitri Maziuk wrote: >> Chad Emahizer wrote: >>> I think I might be restating a bit here from what others have already said, >>> but Trac does (or can do) what you want it to do. It is flexible and >>> doesn't force its own "business logic" on its users. It basically has to be >>> like that, or it will be targeting only a small portion of the population >>> regardless of whichever specific implementation it would choose to >>> implement. >>> >>> A problem with that approach is that not only do you have to learn a new >>> tool, but you also have to understand the processes your company has in >>> place and then determine ways to configure/utilize Trac to fit in with those >>> processes. >> ... >>> So, maybe the question shouldn't be "How is Trac supposed to be used?". >>> Maybe it should be "What are the processes for my company, and how can I >>> tailor Trac to enforce those processes and make them easier to do?" >> >> There are 2 kinds of users: those who want to tweak software to do what >> they want, and those who're happy to click on a button and let the >> software take them to wherever Bill Jobs (aka Steve Gates) thinks they >> want to go. Those in the second category should probably not use trac, >> linux, or any "programming languages" other than flash. In fairness to Bill Gates, I've found most Microsoft software much more willing to be told to behave the way I want it to behave than Apple software. That's not to say that the MS stuff doesn't have its own set of usability problems--it's usually clunkier and more bloated. I just usually feel far more boxed in when I'm using Apple software. But that's an off-topic discussion so I'll leave it at that. Now Trac, on the other hand, gives me a great deal of freedom. And of course as with any open source software (especially with a less restrictive license) we are free to modify it if there's something specific we need to change about it. And the fact that Trac imposes very little process to begin with, and is very modular, it's a lot easier to modify without stepping on any toes. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
On Tue, Oct 7, 2008 at 3:37 PM, Stedwick <[EMAIL PROTECTED]> wrote: > I'm wondering if it's a philosophical conflict. The people at my > company (myself included) like opinionated software. It's like iTunes. > Everybody hates iTunes because they can't manage their music in their > own unbelievably specific manner. However, if you use iTunes as it was > DESIGNED to be used, you will discover that it's an amazing, excellent > piece of software. I can't imagine managing my music any other way. It > just works so well. You just have to get by the fact that you have to > do things "the Apple way". Believe it or not, the Apple way is usually > pretty good. Perhaps that's it. I think "the Apple way" is awful, and nowhere near what I want. The very *least* iTunes could do is let me enter a format string for how I want files named when I rip a CD, but it can't even do that. But that aside, I'm not sure how else to understand your dilemma with Trac. If you want Trac to dictate how you do your work you could try one of the more structured derivatives like Agilo. But it really depends on what your development process is. You said it yourself--Trac is meant to stay out of the way and mostly only do what you want it to do. If you don't even know what you want to do with it, I can understand how you're stuck. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
On Wed, Oct 08, 2008 at 08:46:48AM -0400, Chad Emahizer wrote: > > Could there possibly be a way to develop and distribute specific > configurations of the trac.ini file and a trac.db file? Maybe it's as > simple as that. I would think some sort of "white paper" would be needed > (maybe documented in the wiki) that explains how the specific process the > specific configuration is supposed to work. Maybe a large(ish) percentage > of processes could be covered by a small(ish) number of specific > implementations. > > I think it is akin to how Apache and mysql was for me when I was trying to > install a certain web-based bug tracking system for the first time. I > didn't know how to run a web server and deal with a db server. More > importantly, I didn't want to learn...had neither the time nor the desire. > So finding the prebuilt and configured Apache release XAMPP by Apache > Friends was the only thing that allowed me to move forward. > > Is it as "simple" as defining and documenting a process, configuring it, > zipping the necessary pieces, and putting it up for distribution? Ok, not > so simple to define said process, but configuring Trac once the hard part is > done is relatively easy I think. It would be nice to have certain plugins > preinstalled too, though I'm sure there's issues with redistributing others' > plugins, even with the positive goal of more adoption of Trac. I've not > tinkered with dropping portions of a configured Trac system into an existing > Track install to see how it reacts... > > This would allow the ability for Trac development to continue on the generic > path it is currently on, yet allow someone to pick a pre-setup configuration > that more closely fits the way they do business so they don't have to get > their hands dirty in the nitty-gritty details. This IMHO is the right direction to go: keep trac generic but allow people ways of easily distributing customized "packages" that can be used to create trac instances. To this end, I've been working on a program called TracLegos (http://trac-hacks.org/wiki/TracLegosScript) that will do just that -- allow packaging and distribution of trac.ini files and requirements files for plugins. The program is still in its infancy, but I'd love feedback on whether this idea is useful to people. It was motivated by this concern coming up again and again. (Nor is TracLegos the only software that does this. TracForge also supports this sort of thing) Hope this is useful, at least in the abstract. Feel free to ticket and ask questions, as I'm very interested in people using this plugin if it does help with this problem. Jeff Hammel The Open Planning Project http://topp.openplans.org IRC: jhammel, k0s > -Original Message- > From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Noah Kantrowitz > Sent: Wednesday, October 08, 2008 3:20 AM > To: trac-users@googlegroups.com > Subject: [Trac] Re: how is trac SUPPOSED to be used? > > This is correct, one of the central design tenets of Trac is that it > enforces as little process on you as possible. This does seem to > backfire sometimes, as there is a large segment of the userbase that > would like more structure than that. If you have a suggestion on how > to resolve this, please let us know, it is frequently debated but > people rarely seem to come up with anything solid. > > --Noah > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
On Wed, Oct 08, 2008 at 08:21:42AM -0400, Chad Emahizer wrote: > > I broke this out into a separate email because otherwise it would be one > huge email that rambled, which I have a tendency to do anyway... > > I might try to do this specific example with milestones. Define a Trac > "milestone" as a merge point in the software, like the one you had two weeks > ago. Assign the tickets to the "next" milestone in line, and when a merge > point happens, create another milestone and send all unresolved tickets to > that new milestone. At any given time you can quickly see what tickets have > been closed by milestone. I wouldn't exactly say that's how I would use the > milestone feature in a perfect world (I like to at least of the pretense of > planning), but it would likely work used that way. As far as how trac is "supposed" to be use with respect to those that want a program to enforce methodology versus a program to support multiple methodologies, it seems to me that using milestones is the trac way of doing what is desired here. Marking things as milestones is probably a good practice anyway for this case as it enables a project manager to think of a group of tickets as a concerted effort instead of the more ad hoc date query. IMHO, Jeff Hammel The Open Planning Project http://topp.openplans.org IRC: jhammel, k0s > > Another approach could be to use the version field. Make set the version > field up to have whatever you want to call the merge points, like the one > you had two weeks ago. Code name them. Refer to a build number. Use a > targeted merge date...whatever. As you close tickets, set the version to > the merge point next in line when it was closed. This isn't exactly right > either, as "Version" would typically (I think) be used to designate what > software version the issue was found in, not the version the issue would be > fixed in. However, that being said, you are free to use it how you like and > define. > > A third could be a custom field. Make a custom field for whatever you want > to call the merge points as said above. As you close tickets, set the field > to the name of the merge point next in line when it was closed. This > approach is a little harder because querying based on custom fields is > tough, or so I have read...I've not done it. I'm fairly confident, as you > pointed out, that if I decided I needed to search custom fields for > something I could find adequate documentation to help me do so, I've just > not had the need. > > Hope I was at least a little helpful. > > Chad > > -Original Message- > From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Stedwick > Sent: Tuesday, October 07, 2008 3:38 PM > To: Trac Users > Subject: [Trac] how is trac SUPPOSED to be used? > > > For example, my boss recently asked me what changes were going to be > moved into the trunk since the last merge two weeks ago, and I thought > to myself, "Oh, I'll just do a search for all the bugs that I fixed in > the past two weeks," but, amazingly, I CAN'T DO THAT. Even using > "custom query" there is no field that allows you to query based on > time. And I certainly don't want to start writing SQL. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Robert C Corsaro wrote: > > Man, you're not supposed to say stuff like that out loud. That's why > everyone hates us! Not everyone, just the second bunch -- us arrogant elitists snobs generally don't have a problem with the idea that trac is not right for everyone. It's the other crowd that tends to fervently believe what's good enough for them must be good enough for jesus and the rest of human species -- and you better like it! Dima --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Dimitri Maziuk wrote: > Chad Emahizer wrote: >> I think I might be restating a bit here from what others have already said, >> but Trac does (or can do) what you want it to do. It is flexible and >> doesn't force its own "business logic" on its users. It basically has to be >> like that, or it will be targeting only a small portion of the population >> regardless of whichever specific implementation it would choose to >> implement. >> >> A problem with that approach is that not only do you have to learn a new >> tool, but you also have to understand the processes your company has in >> place and then determine ways to configure/utilize Trac to fit in with those >> processes. > ... >> So, maybe the question shouldn't be "How is Trac supposed to be used?". >> Maybe it should be "What are the processes for my company, and how can I >> tailor Trac to enforce those processes and make them easier to do?" > > There are 2 kinds of users: those who want to tweak software to do what > they want, and those who're happy to click on a button and let the > software take them to wherever Bill Jobs (aka Steve Gates) thinks they > want to go. Those in the second category should probably not use trac, > linux, or any "programming languages" other than flash. > > Dima > Man, you're not supposed to say stuff like that out loud. That's why everyone hates us! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Chad Emahizer wrote: > I think I might be restating a bit here from what others have already said, > but Trac does (or can do) what you want it to do. It is flexible and > doesn't force its own "business logic" on its users. It basically has to be > like that, or it will be targeting only a small portion of the population > regardless of whichever specific implementation it would choose to > implement. > > A problem with that approach is that not only do you have to learn a new > tool, but you also have to understand the processes your company has in > place and then determine ways to configure/utilize Trac to fit in with those > processes. ... > So, maybe the question shouldn't be "How is Trac supposed to be used?". > Maybe it should be "What are the processes for my company, and how can I > tailor Trac to enforce those processes and make them easier to do?" There are 2 kinds of users: those who want to tweak software to do what they want, and those who're happy to click on a button and let the software take them to wherever Bill Jobs (aka Steve Gates) thinks they want to go. Those in the second category should probably not use trac, linux, or any "programming languages" other than flash. Dima --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
well, out of the box, trac does have a usage workflow. new->assigned- >closed if you are after something a little more "common" try the enterprise workflow in the contrib directory. that said, it sounds like your group is perfectly happy being stuck with something that is not customizable (or easily customized). in that case, you might consider something else, but with the caveat that nobody gets to ask for customizations (maybe aside from themes/skins) Trac is a bit of labor to get it tweaked to exactly what fits your organization. The flip side, is, well, it's worth it because you CAN if you're agile, you could look at agilo. there is a release candidate that runs on 0.11 and looks very complete. Even this still allows a ALOT of customization, which I find a good thing, but out of the box, it's good to go. in order to do your date searching you mentioned, you will need to write sql. there are some examples around on how to get this, so you really only need to find it and cut and paste into a query. (sorry I don't have a link atm, but I found one a while back that finds when a ticket TRANSITIONED to closed, which was perfect) however, another option is to add the DateTime plugin, and add a custom field to tickets which people are required to fill in with the current date when they close a ticket. Or you use more milestones, and assign ticket to the milestone for the last to weeks. if it's closed, and milestone matches...etc. this would be more towards the "sprint" model of scrum. I will go back to say, I bet even with an out of the box solution, your group will want SOME sort of customization, which might be difficult if not impossible with other systems. (such as custom workflows, particularly to the level Trac has them.) The subversion hooks are really nice as well. the ability to update a ticket when you check in a file, just via the comments, adds to productivity and traceability. This again, is something you need to enable/configure, since trac doesn't force you to even use source control at all. Still sounds like the best route for you personally might be somehting else that is out of the box, and inflexible. and then they are just stuck with it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Also sorry if this double posts! The first attempt also seems to not have worked... I broke this out into a separate email because otherwise it would be one huge email that rambled, which I have a tendency to do anyway... I might try to do this specific example with milestones. Define a Trac "milestone" as a merge point in the software, like the one you had two weeks ago. Assign the tickets to the "next" milestone in line, and when a merge point happens, create another milestone and send all unresolved tickets to that new milestone. At any given time you can quickly see what tickets have been closed by milestone. I wouldn't exactly say that's how I would use the milestone feature in a perfect world (I like to at least have the pretense of planning), but it would likely be sufficient if used that way. Another approach could be to use the version field. Make set the version field up to have whatever you want to call the merge points, like the one you had two weeks ago. Code name them. Refer to a build number. Use a targeted merge date...whatever. As you close tickets, set the version to the merge point next in line when it was closed. This isn't exactly right either, as "Version" would typically (I think) be used to designate what software version the issue was found in, not the version the issue would be fixed in. However, that being said, you are free to use it how you like and define. A third could be a custom field. Make a custom field for whatever you want to call the merge points as said above. As you close tickets, set the field to the name of the merge point next in line when it was closed. This approach is a little harder because querying based on custom fields is tough, or so I have read...I've not done it. I'm fairly confident, as you pointed out, that if I decided I needed to search custom fields for something I could find adequate documentation to help me do so, I've just not had the need. Hope I was at least a little helpful. Chad -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Stedwick Sent: Tuesday, October 07, 2008 3:38 PM To: Trac Users Subject: [Trac] how is trac SUPPOSED to be used? For example, my boss recently asked me what changes were going to be moved into the trunk since the last merge two weeks ago, and I thought to myself, "Oh, I'll just do a search for all the bugs that I fixed in the past two weeks," but, amazingly, I CAN'T DO THAT. Even using "custom query" there is no field that allows you to query based on time. And I certainly don't want to start writing SQL. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Sorry if this double posts! The first attempt at responding seems to not have worked... I think I might be restating a bit here from what others have already said, but Trac does (or can do) what you want it to do. It is flexible and doesn't force its own "business logic" on its users. It basically has to be like that, or it will be targeting only a small portion of the population regardless of whichever specific implementation it would choose to implement. A problem with that approach is that not only do you have to learn a new tool, but you also have to understand the processes your company has in place and then determine ways to configure/utilize Trac to fit in with those processes. In some cases you might have to recognize that you don't have processes so you'll have to invent them, then figure out what you want Trac to do, then figure out how to make Trac do that...quite daunting in some cases. The good news is that Trac will allow you to do those things. Unfortunately that means there's some work involved. It is not something that you can unzip and put in a directory and have it run tailored to your specific business logic right out of the box. So, maybe the question shouldn't be "How is Trac supposed to be used?". Maybe it should be "What are the processes for my company, and how can I tailor Trac to enforce those processes and make them easier to do?" Chad -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Stedwick Sent: Tuesday, October 07, 2008 3:38 PM To: Trac Users Subject: [Trac] how is trac SUPPOSED to be used? This is going to sound like a rather vague question, but how is trac SUPPOSED to be used? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Could there possibly be a way to develop and distribute specific configurations of the trac.ini file and a trac.db file? Maybe it's as simple as that. I would think some sort of "white paper" would be needed (maybe documented in the wiki) that explains how the specific process the specific configuration is supposed to work. Maybe a large(ish) percentage of processes could be covered by a small(ish) number of specific implementations. I think it is akin to how Apache and mysql was for me when I was trying to install a certain web-based bug tracking system for the first time. I didn't know how to run a web server and deal with a db server. More importantly, I didn't want to learn...had neither the time nor the desire. So finding the prebuilt and configured Apache release XAMPP by Apache Friends was the only thing that allowed me to move forward. Is it as "simple" as defining and documenting a process, configuring it, zipping the necessary pieces, and putting it up for distribution? Ok, not so simple to define said process, but configuring Trac once the hard part is done is relatively easy I think. It would be nice to have certain plugins preinstalled too, though I'm sure there's issues with redistributing others' plugins, even with the positive goal of more adoption of Trac. I've not tinkered with dropping portions of a configured Trac system into an existing Track install to see how it reacts... This would allow the ability for Trac development to continue on the generic path it is currently on, yet allow someone to pick a pre-setup configuration that more closely fits the way they do business so they don't have to get their hands dirty in the nitty-gritty details. Chad -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Noah Kantrowitz Sent: Wednesday, October 08, 2008 3:20 AM To: trac-users@googlegroups.com Subject: [Trac] Re: how is trac SUPPOSED to be used? This is correct, one of the central design tenets of Trac is that it enforces as little process on you as possible. This does seem to backfire sometimes, as there is a large segment of the userbase that would like more structure than that. If you have a suggestion on how to resolve this, please let us know, it is frequently debated but people rarely seem to come up with anything solid. --Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
I broke this out into a separate email because otherwise it would be one huge email that rambled, which I have a tendency to do anyway... I might try to do this specific example with milestones. Define a Trac "milestone" as a merge point in the software, like the one you had two weeks ago. Assign the tickets to the "next" milestone in line, and when a merge point happens, create another milestone and send all unresolved tickets to that new milestone. At any given time you can quickly see what tickets have been closed by milestone. I wouldn't exactly say that's how I would use the milestone feature in a perfect world (I like to at least of the pretense of planning), but it would likely work used that way. Another approach could be to use the version field. Make set the version field up to have whatever you want to call the merge points, like the one you had two weeks ago. Code name them. Refer to a build number. Use a targeted merge date...whatever. As you close tickets, set the version to the merge point next in line when it was closed. This isn't exactly right either, as "Version" would typically (I think) be used to designate what software version the issue was found in, not the version the issue would be fixed in. However, that being said, you are free to use it how you like and define. A third could be a custom field. Make a custom field for whatever you want to call the merge points as said above. As you close tickets, set the field to the name of the merge point next in line when it was closed. This approach is a little harder because querying based on custom fields is tough, or so I have read...I've not done it. I'm fairly confident, as you pointed out, that if I decided I needed to search custom fields for something I could find adequate documentation to help me do so, I've just not had the need. Hope I was at least a little helpful. Chad -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Stedwick Sent: Tuesday, October 07, 2008 3:38 PM To: Trac Users Subject: [Trac] how is trac SUPPOSED to be used? For example, my boss recently asked me what changes were going to be moved into the trunk since the last merge two weeks ago, and I thought to myself, "Oh, I'll just do a search for all the bugs that I fixed in the past two weeks," but, amazingly, I CAN'T DO THAT. Even using "custom query" there is no field that allows you to query based on time. And I certainly don't want to start writing SQL. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
I think I might be restating a bit here from what others have already said, but Trac does (or can do) what you want it to do. It is flexible and doesn't force its own "business logic" on its users. It basically has to be like that, or it will be targeting only a small portion of the population regardless of whichever specific implementation it would choose to implement. A problem with that approach is that not only do you have to learn a new tool, but you also have to understand the processes your company has in place and then determine ways to configure/utilize Trac to fit in with those processes. In some cases you might have to recognize that you don't have processes so you'll have to invent them, then figure out what you want Trac to do, then figure out how to make Trac do that...quite daunting in some cases. The good news is that Trac will allow you to do those things. Unfortunately that means there's some work involved. It is not something that you can unzip and put in a directory and have it run tailored to your specific business logic right out of the box. So, maybe the question shouldn't be "How is Trac supposed to be used?". Maybe it should be "What are the processes for my company, and how can I tailor Trac to enforce those processes and make them easier to do?" Chad -Original Message- From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Stedwick Sent: Tuesday, October 07, 2008 3:38 PM To: Trac Users Subject: [Trac] how is trac SUPPOSED to be used? This is going to sound like a rather vague question, but how is trac SUPPOSED to be used? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Noah Kantrowitz kirjoitti: > On Oct 7, 2008, at 12:37 PM, Stedwick wrote: > >> This is going to sound like a rather vague question, but how is trac >> SUPPOSED to be used? >> >> The reason I ask is because we use trac at my company, but we are >> thinking of switching to something else. Nobody at my company seems to >> like it. I just came on board a month ago, and I've never used trac, >> and it's kind of been placed upon me to research alternatives, but I >> figure that trac is used everywhere so it's got to be good and we are >> probably just using it wrong. >> >> However, a month has gone by, and I really can't figure trac out. It >> doesn't seem to work, or do anything at all, for that matter. I'm kind >> of stymied. I've heard this from other people as well; trac is just >> baffling and weird. I think I've read that track is supposed to "adapt >> to YOUR workflow, and work the way YOU want it to", but it seems to me >> that it has no workflow at all. > > This is correct, one of the central design tenets of Trac is that it > enforces as little process on you as possible. This does seem to > backfire sometimes, as there is a large segment of the userbase that > would like more structure than that. If you have a suggestion on how > to resolve this, please let us know, it is frequently debated but > people rarely seem to come up with anything solid. This is something that is Trac power and weakness. Most Trac like software establish some sort of workflow that you must follow, Trac instead is a liberate in that matter. One problem with corporate users often seek ready to use solutions that have quite straight forward workflows and ways to use software. With Subversion you can do pretty much everything that you do with normal files, svnbook just represent one "trunk, tags and branches" way to work, but people seem to use that quite often. http://trac.edgewall.org/wiki/TracBooks contains one book to read about "realworld" usage. I haven't read it though so hard to tell is it any good. -- Jani Tiainen "Tein sein mihin näillä lahjoilla pystyin. Tein sen, en yhtään enempää." - Martti Servo & Napander --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: how is trac SUPPOSED to be used?
Noah Kantrowitz wrote:
> On Oct 7, 2008, at 12:37 PM, Stedwick wrote:
>
>> This is going to sound like a rather vague question, but how is trac
>> SUPPOSED to be used?
[snip]
For a more structured, restricted, but still powerful way of using Trac
to manage bugs as well as handle project management, have a look at
http://www.agile42.com/ which implements Agile Development using a
customised version of Trac (based on 0.9.x)
If you don't know much about Agile development, this will probably
confuse you more than help, so it's worth reading some of their links
("Scrum in a nutshell", etc) or
http://en.wikipedia.org/wiki/Agile_software_development or whatever else
google throws at you.
HTH,
--
Iain Buchanan
Phasers locked on target, Captain.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
begin:vcard
fn:Iain Buchanan
n:Buchanan;Iain
email;internet:[EMAIL PROTECTED]
tel;work:+61 (0)8 8947 0933
x-mozilla-html:FALSE
version:2.1
end:vcard
[Trac] Re: how is trac SUPPOSED to be used?
On Oct 7, 2008, at 12:37 PM, Stedwick wrote: > > This is going to sound like a rather vague question, but how is trac > SUPPOSED to be used? > > The reason I ask is because we use trac at my company, but we are > thinking of switching to something else. Nobody at my company seems to > like it. I just came on board a month ago, and I've never used trac, > and it's kind of been placed upon me to research alternatives, but I > figure that trac is used everywhere so it's got to be good and we are > probably just using it wrong. > > However, a month has gone by, and I really can't figure trac out. It > doesn't seem to work, or do anything at all, for that matter. I'm kind > of stymied. I've heard this from other people as well; trac is just > baffling and weird. I think I've read that track is supposed to "adapt > to YOUR workflow, and work the way YOU want it to", but it seems to me > that it has no workflow at all. This is correct, one of the central design tenets of Trac is that it enforces as little process on you as possible. This does seem to backfire sometimes, as there is a large segment of the userbase that would like more structure than that. If you have a suggestion on how to resolve this, please let us know, it is frequently debated but people rarely seem to come up with anything solid. > > For example, my boss recently asked me what changes were going to be > moved into the trunk since the last merge two weeks ago, and I thought > to myself, "Oh, I'll just do a search for all the bugs that I fixed in > the past two weeks," but, amazingly, I CAN'T DO THAT. Even using > "custom query" there is no field that allows you to query based on > time. And I certainly don't want to start writing SQL. > Time-based queries were indeed one of the major deficienes of the query system vs. reports. I believe this feature has been checked in to trunk, and so will be part of 0.12 when it is released. In the mean time, yes you have to write SQL. The query system is no where near a full replacement for reports, which is why despite their ugliness reports have not been removed yet. > I read over the documentation, and it does a good job of explaining > WHAT things do, but I can't find anywhere that explains what it was > DESIGNED to do. How were tickets DESIGNED to be used, if they weren't > designed to be used based on date? To me, the date seems the most > obvious thing to track bugs by, other than perhaps by severity. The > date reported, the date fixed, the date released. > > I'm wondering if it's a philosophical conflict. The people at my > company (myself included) like opinionated software. It's like iTunes. > Everybody hates iTunes because they can't manage their music in their > own unbelievably specific manner. However, if you use iTunes as it was > DESIGNED to be used, you will discover that it's an amazing, excellent > piece of software. I can't imagine managing my music any other way. It > just works so well. You just have to get by the fact that you have to > do things "the Apple way". Believe it or not, the Apple way is usually > pretty good. > > I'm concerned that the trac way is... well, I don't think it even has > a way. Does it? I can go to the subversion documentation, or the git > documentation, and it will tell me EXACTLY how I'm supposed to manage > my source code, how my teams are supposed to work together, how > merging is supposed to work, what the workflow is, et cetera. There > are a couple of options of course, but at least they are well > documented options. > > Anyway, sorry for the strange question. Can anybody explain to me how > a usual "trac workflow" is supposed to look? Or a good website that > goes over how people generally use trac? You can look at the TracUsers page to see other people using Trac. Some major places I know you can look include Trac itself, dev.laptop.org, developer.pidgin.im, trac.adiumx.com. Beyond that you will need to sit down and figure out what works best for you and your team. --Noah --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
