Re: IPFire Wiki Workflow

["R. W. Rodolico" <rodo@dailydata.net>]

[-- Attachment #1: Type: text/plain, Size: 6199 bytes --]



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
> 

-- 
R. W. "Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
http://www.dailydata.net
214.827.2170


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: rodo.vcf --]
[-- Type: text/x-vcard, Size: 245 bytes --]

begin:vcard
fn:R. W. Rodolico
n:Rodolico;R. W.
org:Daily Data, Inc.
adr:;;POB 140465;Dallas;TX;75214-0465;US
email;internet:rodo@dailydata.net
title:President
tel;work:214.827.2170
url:http://www.dailydata.net
version:2.1
end:vcard