Hi.
WebIssues is a fine and relatively simple to use project. I'm thinking of deploying it in the company i work as a BugTracker for a couple of projects i have. I have some concerns though.
I see there are many ideas (http://wiki.mimec.org/wiki/WebIssues/Roadmap) but there is no clear indication on whether the project is active or if there are certain features selected to be implemented for the next release (whenever this may be). From what i've understood, this is a one-man show, so it solely depends on the time this one developer can spare on it. This makes the future of the project "misty", both "feature-wise" and "support-wise".
Mimec, it would be nice to have some comments from you on the future of WebIssues. The time you've already spend on this project is much appreciated. It's quality is much better than other free bug trackers i've tried, more user-friendly and visually appealing. Understandably, real-life always takes precedence so it would be nice to know if you have time to spare on it and in general, your hopes about its future.
Thank you.
Hello,
It's true that there hasn't been a lot of activity in this project recently. Partially it's because I don't have much time for it anymore and - as you said - it's mostly a one-man show. However, the other reason is that the project is quite mature and complete feature-wise after almost 10 years of development. There is still a long list of ideas for future versions, but they are mostly "nice to have" features, not things that people can't live without. At least that's my impression from requests posted here and my own experience with using WebIssues. Also, support-wise I think that the project is still in good shape, because the documentation is quite good, the forum serves as a rich knowledge base, and I always try to help and give support when people ask for it.
Regards,
Michał
Hi,
first of all: Thank you for developing this. It is a really good tool and it helps us alot in our company.
My question: Did you consider moving the code from your SVN to GitHub? It would make contributing to the project a bit easier I think.
Regards,
duderino :)
Hi and thanks for your answer, which i'm quoting below in bold.
Partially it's because I don't have much time for it anymore and - as you said - it's mostly a one-man show.
Well, that's understandable, respected and makes me feel a little sad for the future of the project, but i guess that's life... :)
the other reason is that the project is quite mature and complete feature-wise after almost 10 years of development
Well, this is partly true (for me at least). The project is indeed mature and works pretty well, but IMHO there are a few things that would be more than "nice to have". I'll state them below hoping for them at some point in the future. Some of them are already in your list.
1. "roles and groups". To me this is a "must", at least in a simpler form. I miss the simple ability to define a read-only user role in a project. I guess with "roles and groups" you have a larger concept in your mind but IMO just the addition of a "read-only user" might solve quite a few things (as a simple first-step at least).
2. "LDAP authentication". This indeed would be helpful but for small teams, i guess it falls into the "nice-to-have" category where one could live with the burden of having to maintain only a few users.
3. "calendar view, Gantt chart". Another "nice-to-have" feature which i'm guessing might need a lot of work.
4. "displaying attached images in-line". Would be nice, could be tricky to implement though (what about large images, will they be shrinked to fit in page and expanded when you click on them?).
5. A way to organize projects into folders. IMO this one would be more important than 2, 3 and 4 all together. In my case, i have a few single software projects which are composed of several subsystems each. I also have several common libraries which are in fact standalone projects but are used by all other projects. I have defined each library and also each subsystem as standalong projects which is not the most convenient and organized scheme (it's too 1-D). It would be more clear if there was a way to add multiple levels of folders (much like one can add OUs in the "Active Directory Users and Computers" tool) and place those projects under them (like a treeview). Folders would have no actions on them, for simplicity reasons. No crazy things like "inheritance" of any kind. Just plain folders for better organization of things. I'm not expanding it any more but you get a general idea of what i'm proposing. If you wish, i could expand on that.
6. Ability to select multiple items in a list (tasks/bugs) so they can be massively moved to another folder. Seems like a "must". As is now, it's quite a burden to do such a thing for a large amount of entries. Perhaps it could be done from another screen in order not to break the existing one, although this might not be the best way to go.
From all of the above, i would rate 1, 5 and 6 as the most important ones. They would help much to have a better look 'n' feel of the whole package of projects i intend to manage.
support-wise I think that the project is still in good shape, because the documentation is quite good, the forum serves as a rich knowledge base, and I always try to help and give support when people ask for it.
Well, that's true. Support-wise, the work you've done on this project is quite good and it's comforting that even though real-life(tm) is putting pressure on you, you still manage to provide assistance on it. Thanks for that, it's really important and appreciated.
I also have some concerns here, on how an update on WI would be applied. In my setup, i have changed some of the existing attributes of Issue Types and added a few new. I'm concerned, how easy would it be to install a future WI update to a new version? What if a new attribute is added to an Issue Type in a newer version? Would it be automatically added upon installation to the existing projects/tasks in the DB? Would the installation also re-add the attributes i have modified/deleted?
Well, too many things in a single post. I'll stop here. :)
First of all, thank you for your valuable feedback :).
I agree that adding more project-level roles, including the read-only role, is probably the most important missing feature in WebIssues. When I planned version 1.2 some time ago, it was one of the top level requirements. I also planned to implement groups and LDAP, though this is only important for really large systems and I'm not sure how many WebIssues installations fall into this category.
When it comes to organizing projects into folders, that's more tricky. I understand your use case and it's probably quite a common problem. However, when I designed WebIssues, I envisioned that in a typical scenario there would only be a small number of projects and folders. Basically one project for each group of people and one folder for each issue type. Working with a large number of folders is quite inconvenient, because you have to navigate through multiple folders to see if there are some new or updated issues - by the way, that's the reason I implemented the "global" lists of issues that basically ignore projects and folders altogether. In most cases you can mark separate subsystems using a simple drop-down attribute instead of using separate projects or folders, unless you really need to control permissions for individual subsystems. People who are only interested in a few subsystems can create views that display only issues associated with these subsystems.
The ability to perform basic operations on multiple selected issues is also very important and it was included in my plan for version 1.2.
Now to answer your question, you don't have to worry about future updates. The initial set of default issue types and attributes is only installed when you set up a new WebIssues server for the first time. The existing types and attributes are not modified in any way during an update.
@duderino: I thought about moving to GitHub, especially after all the controversies around SourceForge, but so far it seems that SF is still in a decent shape. Also I got used to SVN a lot and I think that most developers still know how to use it, so I think it's not a major factor when it comes to encouraging or discouraging potential contributors :).
Regards,
Michał
Hi. Thanks for clarifying all those things. I hope at some point you manage to find the time (and peace of mind) to implement and release 1.2. It seems it may have several good new features.
Working with a large number of folders is quite inconvenient, because you have to navigate through multiple folders to see if there are some new or updated issues
Indeed, but you could leave this decision to the site admin, right? If he likes users hunting him for creating a 10-level deep tree... :)
by the way, that's the reason I implemented the "global" lists of issues that basically ignore projects and folders altogether.
Yup. That's probably a useful feature although in the setup i'm testing (having 5-6 projects and most users viewing up to 2 of them), i wish there was a user-level option near the tree so that the user could hide it.
In most cases you can mark separate subsystems using a simple drop-down attribute instead of using separate projects or folders, unless you really need to control permissions for individual subsystems.
That's what i had in mind (to be able to control permissions for individual subsystems). :) Also, another small problem related to this, that puzzled me how to implement it is the fact that there are tasks we gather and at some point implement and release them, so there is a need to group them somehow to indicate the release. I though of two solutions, one to have a "group" combo field in the tasks screen of a project and the other was to create separate tasks folders with the names of the groups (i.e. phase 1, phase 2, etc). The 2nd solution seemed better to me but after a while, each project will end-up having 10-20 subfolders which does not seem very convenient. The "folders" i proposed in my previous post could be a solution to this if one could create an "old" folder and move all old tasks folders to it. From your reply though, i'm now re-thinking solution #1, even though it complicates things because there must be a separate "group" combo field for every project (with new values constantly being added to it).
P.S.: having said the above, i got the following idea: it would be nice if in a combo list, one could set "[top]" or "[Bottom]" as a default field value in attributes (like "[Me] in Users), so when a new item is added at the top or bottom of the list, the system would select this a a default value.
P.S.2: Thanks for clarifying the setup thing to me. This was a big concern for me.
N.A.