On 07/11/2013 05:01 AM, Michael Tremer wrote:
Thank you for your feedback, Rod.
On Thu, 2013-07-11 at 02:28 -0500, R. W. Rodolico wrote:
Hey, I'm one of those people in Section 3 that Michael talks about. I'm "on" the documentation team, but really don't do much.
I wasn't aware that you were on the team.
"On the team" may be over stating it. One time, several months ago, someone mentioned on this list that something needed to be changed in the wiki; updates by a native English speaker. I looked at it, volunteered to do it and did it. That is the one and only time I've done anything on the documentation.
That incident is what led to my observations. I wanted to do something, but was very unsure of the scope of changes: make simple grammatical/spelling corrections or rewrite the entire thing. I also remember it was somewhat interesting figuring out the markup language.
I think, for me at least, the problem is two-fold. First, I'm confused as to what I should do. Second, I'm unsure of how I do it.
For me, personally, if I had a small, defined task that I was to do, and knew who it was that was supposed to approve what I am supposed to do, you might get a little work out of me.
I also agree it is the organization of the the wiki that makes it difficult. The information is there, and a lot of it is very good. But, it was only on my 3rd or 4th install that I realized it even existed.
If I would need to bring all this to terms I would call it "awareness".
Everyone (literally - people on and off the documentation team) should be aware of what is been done at the moment. What has been done recently and what will be done in the future. On top of that it would be good to know who is doing what, so that I can contact that person if I have got something to contribute or what ever...
I, like everyone, have other things that I must do to pay the rent and such. However, I love IPFire, and use it quite a bit. I want to give back. The only thing I've done so far is to make a few minor changes in one page, because someone mentioned it needed to be done. I saw other things that needed to be changed, but did not want to "step on anyone's toes" (American for cause bad feelings by changing something someone else did, and them feeling like I was saying it wasn't good enough).
I like most of what Michael said. I think that under these circumstances, I might actually be able to be less of a leech and actually contribute.
I would recommend that the task be small and well defined, in both scope and date when the results were expected. And, that would be a total pain for Erik. However, I think that having a task that could be completed in a couple of hours, and was due within a week, would result in more being done on this.
The due dates. This is a huge concern for me and we also have this issue in the development team. We all do not work full time on the project, so the project has a bit of a lower priority to us than paying rent and things like that.
Sometimes there is a lot of spare time that can be invested into the project and sometimes there is not. It varies quite a bit and planning with that is hard.
If someone has a solution how to define due dates in a way that we don't set them too far in the future and everybody is idle and that we don't set them too early because there may be other things that are more important and need to be done first.
A strict two week schedule may work for some tasks, but not for others. Can we add something like a "fast sprint" of only one week? Should we set no due dates at all?
I run a small computer consulting business where I have a couple of tech's working for me, either as consultants or employees. Some of our tasks take longer, some are quick.
In some ways it is similar to IPFire. I am really the only full time employee; everyone else works either as needed/as available or part time. So, I have to keep in mind the constraints on their time (they all have other jobs). However, they do work for pay, so that is a difference.
We use RequestTracker (http://bestpractical.com/rt/), and no, I am not suggesting that for IPFire. I'm simply pointing out how we do things.
When a task comes in, we either leave it unassigned in the general queue, or I assign it to someone. Theoretically, the other techs also look at the unassigned tickets and, if it is in their skill set, they take the task (actually, they are getting better at it now).
However, there is a nice, simple list everyone in the organization can look at, of tasks that are to be done by them. They are arraigned by priority, and there is a column showing how long it has been open, and also how long it has been since they did anything. Tech's log in, look at their tasks, then work on one or more of them. When the task is complete, they set the status to "resolved" and it is removed from active tickets, but stored in the system for reference in the future.
Again, I'm not trying to get IPFire to move to Request Tracker. It took me a while to install and configure, and there are other solutions that may work better for this project (bugzilla is one). However, I do see some advantages to a system like this. Everyone sees their tasks (and the tasks assigned to others). When tasks are completed, they are retained so we can look at historical data (for clients who have similar problems), etc...
A quick scan of the Request Tracker wikipedia entry showed lists of about two dozen similar solutions. https://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems shows a comparison and https://en.wikipedia.org/wiki/Request_Tracker is the Request Tracker page.
If someone wants to see what I'm talking about, I'd be happy to give you a temporary login to it, or maybe build a separate instance you could look at and play with.
My opinion. I would like to help, I just am not sure what to do to help.
We will figure that out :)
-Michael