Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm introducing a new Project-Management software in my company and looking into possible opensource software. Since i'm familiar with python, trac would be my first choice. but it looks like it is mostly used for software-projects, which isn't the case in my company.
Furthermore, time tracking is a big issue. We have multiple develeopers and each one should be able to track their time on the projects he worked on. This times schould be exported into csv at the end of each month (although i think i could to the export also directly from the DB)
So have anyone experiance with trac in non-software projects? It would be great to her some experiance from you, saves a lot of time for me ;)
We currently use Trac for our IT team. It allows us to track things such a help desk tickets, server projects and website changes. We have been doing this for over a year now and it is working great. It is even starting to spread out into other teams for managing team tasks!
As for pulling hours, etc from Trac, we use a custom field and then pull the data through the report module (now deprecated) and direct database access. In the past we have used plugins such as these.
http://trac-hacks.org/wiki/TimingAndEstimationPlugin
http://trac-hacks.org/wiki/TracHoursPlugin
We have also tied Trac into AD for authentication which allows for a single shared pasword for Trac and our domain.
For what it's worth I've setup a couple of Trac instances, that are totally unrelated to software development. Trac works well as a low entry barrier platform for any stuff I've encountered so far. We have all sorts of applications running, and especially the attitude to wikify anything is very nice - wiki markup in tickets, consistent link syntax across modules (changeset comments, tickets, wiki pages), etc. And I can confirm the viral effect, that a well-established Trac application has.
Trac it's very slim at initial setup, but feature-rice and modular from the ground to satisfy growing demand. For things like time-tracking you could use solutions like the TimingAndEstimationPlugin mentioned by Josh before as well. In general trac-hacks.org is a crowded space, not exactly easy to pick what you want, but a valuable resource anyway.
Make sure to ask at the trac-users mailing list and IRC channel #trac at irc.freenode.net, if you encounter some challenges. It's a small developer community, but a friendly one, and with some Python experience you'll surely find your way. Source code and wiki docs at trac.edgewall.org are always your friend.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I work at a software company that maintains some products.
We use a "bugtracker" to manage all tasks related to the products in question.
We work with Scrum, and the company's routine is basically the following:
The customer comes in contact with the support and requests to solving a problem or implementing a feature.
The owners of the product group the tasks in order of priority and directs them to a Sprint.
Developers finalize the task and ultimately are required to fill out a kind of "changelog".
The testers ensure that the coding of the developers was done correctly and end the call.
Here is my problem:
Developers do not like to fill the "changelog", and usually forget to do it.
Here is my question:
Who should complete the "changelog"? The developers and testers?
This "changelog" is sent to end customers at the end of each Sprint, and basically serve to explain in nontechnical what has been resolved or implemented in software.
And then, who should do it? Developers and testers?
This isn't a Scrum question, it reads like a process question. Can I also state that Scrum doesn't really lend itself well to maintenance work and that you may be better trying Kanban in that situation?
That said, although Scrum does not include any reference to changelog artifacts, I'd say that it's a team responsibility to ensure that the changelog is updated (as opposed to any one developer or tester). To act as a reminder, The team may want to consider adding this requirement in to their 'Definition of Done'.
Hope that helps.
Find out what works best for your team. It seems odd that developers/testers would be communicating with customers directly. I would expect that to be the role of the support team who was originally in contact with the customer.
As you said in your comment, they are likely dragging their feet because it's not what they are good at and thus they don't like doing it.
A couple things to try:
Put everybody in a room and talk it out (doesn't work if there are too many people - maybe just get the dept heads). We need this to get done, it isn't getting done, why not and who has ideas how to fix this?
I'm not sure why the customers even need a description of what was changed - I'm picturing a "how we fixed it" situation. Who cares how, just that it is fixed. I'm saying to re-examine if this is necessary - perhaps there is an easier suitable substitute.
Try to automate it. If the customer does need a hand holding explanation of how it was fixed and all they really need to know is that it was fixed, perhaps you could automate your bug tracking tool such that the customer who reported the issue is notified when that ticket is closed - or rather, when it is deployed and visibly fixed for the customer.
Biggest piece of advice is to not make this a blame game situation. Your coworkers aren't unreasonable people - if they are resistant, then perhaps the process is too heavy. Be open to alternative solutions.
FYI - This kind of question may do better over at pm.stackexchange.com
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm responsible of finding a good way to document the software project I'm working on.
What things are important to document? Should documentation of code and design mainly be in the code in the form of comments? Should we put text files or Word documents directly in the source control togetether with code? Should we use a wiki?
Factors to think about include how easy it is for the current team to create the documentation, and how easy it is for other developers to find, correct and extend the documentation later. My experience from many projects is that developers tend to not write documentation because the system for writing it is too complex or developer unfriendly, and that after a few years, new developers can hardly find the little documentation that was written.
I'm interested in what approaches you have used in similar projects. What worked well, what did not work well, and why?
Some key facts about the project:
The platform is C# and .NET.
We use Visual Studio and Team Foundation Server for source control and work item (task) management.
We use Scrum and test-driven development and are inspired by domain-driven design.
The software consists of a collection of web services and two GUI clients.
Other clients are going to integrate with the web services in the future. The integration will be done by other developers on other teams (so the web services form a kind of API).
SharePoint is heavily used throughout the development environment. Most projects have a SharePoint site, including ours.
On our project's SharePoint site we currently have a bunch of MS Office documents on things like requirements, design, presentations for stakeholders etc. Keeping everything up to date is hard.
We also have a SharePoint wiki for the development team only, where we document things in an unstructured manner as we go along. Examples include how our build scripts are organized, our testing policy, coding guidelines.
The software is an in-house application in a fairly big financial institution.
The software is developed by a team of six people over a period of ~1 year.
The developers are consultants hired in for this project only, and will not be available to help in the future (unless the client decides to pay for it).
The client has few guidlines for how this kind of project should be documented.
I think the most important things to document are the decisions. This goes for everything from requirements to architectural choices. What are the requirements of module X? How are these requirements represented in the architecture? Why did you choose architectural pattern A over B? What are the benefits? The same goes for source code: it is common knowledge that commenting the why is way better than the how.
How you document these decisions does not matter that much in my opinion, whether you use a Wiki or a Requirements document made in Word. More important is that these documents are always up-to-date and that it is easy for anyone to access them. This can be achieved by using a wiki, or placing the documents under source control, as you say. If only a few have access to them, they are more likely not to get updated, and not to be read when necessary.
We use a Wiki for our current project and it works very well. It is easy to access for anyone (developers, managers, and customers) and a history can track changes, so you know what has been changed and why. Furthermore, we try to document the code in a meaningful way and document the major design decisions. We try not to document too much, e.g. minor things, as it is always hard to keep those things up-to-date and it is not worth the effort, imho.
Worst for me than lack of documentation is excess of documentation.
Keep in mind that yes: it's really important to document your project, but also that the major part of your documentation is always at risk of never been read at all.
So, I think that a good starting point consist in thinking of your documentation more like something that you may use to introduce new developers to your project than an over detailed description of the inner workings of your software.
G'day,
Definitely use a wiki. I'd recommend TWiki as it's an excellent and extensive implementation of a wiki without being too complicated to install and manage.
Here's a couple of initial thoughts.
Categories:
Start off with an initial ontology of what you want to capture but
allow people to add new categories or sub-categories as required,
allow people to retitle (sub-)categories as required and maybe as agreed for this one so you don't get fragmentation for multiple names for basically the same thing.
let any initial (sub-)categories wither and die if they are left empty. Do this at the end of the project as some areas may only have entries towards the end of a project.
Tagging:
Start using a tag cloud. BTW here's an excellent plug-in available for TWiki to start classifying content early on in the project. Retrofitting tags is almost impossible to do. Starting tagging early also allows people to search for information that may be there already rather than having the same info located in multiple places.
HTH I'll come back and add more points as I think of them.
First and most important, have the comments written in such a way that NDoc can parse them. This is the best way to have the code itself documented, as the developers have to change their development practices very little, and you can generate pages that explain the code without having to look at the code.
Second, getting developers to write documentation is not easy, and getting them to do it might be an exercise in futility. This is where products like Fogbugz come into play. They will help manage the development with tickets, help track check ins, and when your done an iteration, generate release notes.
In conclusion, your best bet is to find the most effective solution that fits in with the devs existing process. If it impacts their development process very little, they will be more likely to adopt the system.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Please feel free to move this to meta/superuser if this is the wrong place. But this is a developer related question.
I have a smallish company with about 10 employees (developers). Often when I am browsing the internet, I come across various techniques and methods which I would like to share with them. Now one way is to simply point them to those links, but that's not too effective as sometimes the link dies, our connectivity is down, people may want to add some comments/thoughts etc.
I am wondering what is the best way to organize all this data. Couple of questions:
Should I use a SO clone? Wiki? Digg clone?
Personally I dont want to use a wiki. I find it to be a pain to create links manually. I just want to post stuff and links and select an appropriate category and people can then view and comment etc.
How to get everyone involved in this process? SO does it well by giving points to users.
How does your company manage information?
Thank you for your time.
I quite liked a process once upon a time.
Start a knowledge base within the company using Blog/Wiki/SharePoint. SharePoint is nice in the fact that it is basically setup and go. You can modify to specific needs down the line. With this you should allow your staff to add posts or blog entries etc, and then once a week/month/whenever you should have a half day "learning" session.
In this session everyone can share idea's and "nice-finds" and then share with their fellow staff; alternatively, you give each member of the team the opportunity to "teach" a session whereby they can share a technology they've found and basically pitch it to the team.
This gives the following:
Adds to teamwork
Gives opportunities to change the way they work, by introducing new technologies
Active learning is always better than passive
The problem comes with people who are introverted, non-confident or simply do not have the time to give lessons, all of which can be overcome by lowering load, allow some to do written presentations, etc.
Hope this helps.
Use a wiki or a blog. Preferably one with both. That way they can search for things and you encourage them to post their own information. Its not easy to get everyone on board but keep trying.
I find the best way to get people involved is by example. Post good stuff and not just 'stuff I found to day about blah....' I read pages out there that all do it link to some new announcement or another - waste of time I think. Better to post somethings of relevance, but not just links. Put some comments along with links.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
If its dead, is there a successor?
For those who didn't know:
The Network News Transfer Protocol or NNTP is an Internet application protocol used primarily for reading and posting Usenet articles (aka netnews), as well as transferring news among news servers.
NNTP isn't dead. It just smells funny.
Sadly, these days if you want to follow 10 different forums then you need to have 10 different accounts and learn 10 different UIs. I like being able to pick the newsreader that I like and have the same interface for all of my newsgroups. OpenID may bring some of this back, but I'm afraid that the "new internet" just doesn't care about interoperability like the "old internet" did.
It is not dead, but still used by guys who do prefer plain-text over animated emoticons and flashy ad-banners.
Seriously, I have been using it since ten years and I cannot detect any drop in the number of articles or users.
It's not dead - there's still plenty of traffic in the public C# group, for instance.
StackOverflow is becoming a pseudo-successor - but only for some kinds of threads. Q&A threads are ideally suited to SO; discussion threads don't work nearly as well here as they do in newsgroups.
I have never been on Usenet. But I use several “private” NNTP servers (disconnected from Usenet), including the awesome NNTP interface to mailing lists: http://gmane.org/
Edit: oh and none of those servers I use needs an "account". Yet they're quite spam-free.
I know many people like myself who still use nntp / usenet on a daily basis. It is an absolutely invaluable tool. I doubt it will go away anytime soon.
It's like the pinball machine of online communities. All the new kids may not know what it's all about and may think it is dead, but it is still alive and kicking and there's still nothing that can compare.
It's not dead (yet?) but it's being replaced by feeds and feedreader (RSS and Atom)
It's nowhere near as relevant as it once was. Nowadays any popular forum is going to be web-based. For example, stackoverflow would be very crap if based around NNTP. You just can't provide the same experience when your interaction with the forum software is so limited.
Another big problem is that you can't display a CAPTCHA over NNTP, or indeed provide any other modern interactive anti-spam measure.
I'd say yes, it's practically dead.
Agreed, NNTP's time is past. We have good connectivity; there is no need to replicate data across multiple servers any more. I use Google Groups in preference to NNTP.
However, NNTP does provide some community assurance against catastrophic failure. There's probably an open-source project in there somewhere for web-based forums to provide this kind of distributed, fault-tolerant, load-balanced services.
The only true NNTP Replacement could be Mailing lists. Not any web-based forum.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What would you suggest for the following scenario:
A dozen of developers need to build and design a complex system. This design needs to be documented for future developers and the design decisions must be noted. These reports need to be made about every two months. My question is how this project should be documented.
I see two possibilities. Each developer writes about the things they helped design and integrate and then one person combines each of these documents together. The final document will probably be incoherent or redundant at times since the person tasked of assembling everything won't have much time to adjust every part.
Assume that the documentation parts from each developer arrive just a few days before deadline. A collaborative system (i.e. wiki) wouldn’t work properly since there wouldn’t be anything to read until a few days before deadline.
Or should a few people (2-3) be tasked with writing the documentation while the rest of the team works on actually developing the system? The developers would need a way to transfer their design choices and conclusions to the technical writers. How could this be done efficiently?
We approach this from 2 sides, using a RUP style approach. In the first case, you'll have a domain expert who is responsible for roughing out the design of what you're going to deliver - with developers chipping in as necessary. In the second case, we use a technical author - they document the application, so they should have a good idea of how it hangs together, and you involve them right through the design and development process. In this case, they can help to polish the design, and to make sure that it matches what they thought was being developed.
We use confluence (atlassian's wiki-like-thing) and document all kinds of different "things". The developers do it continiously, and we push each other for docs - we let peer pressure decide what is necessary. Whenever someone new comes along he/she is tasked with reading through everything and to find out what still is correct. The incorrect stuff is either deleted or updated as a consequence of this. We're happy when we can delete stuff ;)
The nice thing about this process is that the relevant stuff stays and the irrelevant stuff is deleted. We always "got away" from the more formalized demands by claiming that we could always construct the word documents they wanted if "they" needed them. "They" never needed them.
I think alternative 2 is the less agile, because it means a new stage to the project (although it may be in parallel with tests).
If you are in an agile model, then just add documentation (following a guideline) as a story.
If you are in a staged approach, then I would nevertheless ask developers to work on documentation, following some guidelines, and review that documentation along the design and the code. Eventually, you may have a technical writer reviewing everything for proper English, but that would be a kind of "release" activity.
I think you can use Sand Castle to document your project.
Check it out
Sand Castle from Microsoft
It's not a complete documentation, but making sure that interfaces etc. are commented using Doxygen-style comments means writing code and documenting it are closer together.
That way, developers should document what they do. I still think a review by the architect(s) is needed to ensure consistent quality, but ensuring people document what they do is the best way to ensure they follow the architecture.