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.
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?
My opinion. I would like to help, I just am not sure what to do to help.
We will figure that out :)
-Michael