Re: IPFire Wiki Workflow

[Michael Tremer <michael.tremer@ipfire.org>]

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

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