Not so long ago, Joris proposed that we constitute a team of developers
and interested people. Although not many have shown interest (where are
you people??!), there is still the possibility that more join in and
with them there will be an increase in the difficulty of coordinating
efforts.
During the last week a couple of items in the tracker have been the
origin of a long series of questions and problems, amounting to an
absurdly huge waste of time, mainly because it was not clear to me why
something had to be done (or rather not done) in a particular way. So I
just kept asking. In the end the problem was that Joris is working in a
related task ("reorganizations" :-) which will somehow render the
current approach, and any patchy solutions on top of it like mine, obsolete.
Most of the pain and waste of time in that exchange could have been
avoided if either I just shut up and did as I was told (I sometimes
really should, I'm sorry for that) or if a detailed list of the tasks
currently undertaken by each developerhad been available. Preparing and
maintaining this list is in itself a time consuming task whose burden
falls upon every one of us, but I think the net result would be a gain
of time.
So I propose the four of us who are actively committing code at the
moment, and any who are not but anyway work in some part of the project
or wish to do so, input their objectives into the task tracker in
savannah. With details, clear scope and current information or it will
be totally useless. Any ideas or alternative to this approach would be
very appreciated.
If there is to be such thing as a team, then we must act as one. We must
know what the others are doing, why and when, or else there is no
possibility of initiative.
This idea of keeping detailed task lists is evidently most relevant in
relationship to Joris' work, because he is by far the most active
developer and the one with the main goals in his head (I realize the
perceived waste of time my proposal would mean for you, sorry!). The
approach: "contributors should just prepare patches and send them" is
fine when the patches address little, focalized problems which do not
interfere with Joris' current projects, but it's totally inadequate for
long term subprojects.
Now some ranting...
All this is of course partly in my own interest because I like to peek
around the code and hate sticking to one particular task. In my opinion,
cubicle-work is fine for a cubicle-job with corresponding salary and
increasingly depressing workdays, not for a community. There is
naturally the opposite view, that we each ought to do what we are told
to, or what we agreed to in the first place and only under exceptional
circumstances wander out of our domain. When properly implemented, this
is probably more efficient in many (most?) cases and what any project
leader might wish for, but it's not something one usually volunteers
for. After all, I do this for fun.
Take for example the new "persistent storage". What is its intended use?
Does that affect work related to preferences? Should I ditch what I did
with those? And the new buffer related stuff: it renders completely
obsolete my (few) ideas for better project management (and surely is
incompatible with some of them). Or take the search feature or... well,
you get it. The problem is not that my work is ditched because it's
wrong or can be improved (it always can), the problem is that I
shouldn't have started it in the first place!
Well, that's enough ranting for an email. Any ideas on the real issue?
Cheers,
Miguel.
_______________________________________________
Texmacs-dev mailing list
Texmacs-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/texmacs-dev
