|
Hi there,
I have said this before, on my flog as well as on 3D17 as
on IIRC, etc.
Aside from the problems in coding, which I won't comment
on since I am not a coder, there is also a severe lack, in general, of proper
management.
'Proper' may have a different meaning in an Open Source
project, but it is still a good thing to involve as many people as possible who
care enough for the project as possible. Human resources gets wasted in the
current system. People get little to no response, get desillusioned, want to
help but don't know how, get the feeling they aren't heard, etc.
Those things are subjective and it is not always
reflective of reality; sometimes it ca not be helped. Much of the times it could
with a bit more of overall management. Coders have the tendency to be occupied
with the coding, which is on itself not a bad thing. But getting the most out of
a project involves more then just the coding. I suggest a structural change in
how the project is run in order to make it more user-friendly. I am not merely
talking about the freenet-webinterface, I am talking about the involvement in
the project as such.
While coders are important for the actual working of
Freenet, there is no reason why we can not use people with other skills to
participate and help the project in their own way. The current devl-team should
make this possible which would relieve them from secondary tasks and thus give
them more time to code.
Now, because things don't get done by staying vague (there
has been endless discussions enough on this), I will put forward some
pretty clear-cut suggestions:
1)There should be appointed an 'official' webmaster (or
something like that), who deals with things related to the www freenetsite. He
should have full cvs access, and people should be readily able to contact
him.
I know the devl is readely using the cvs already, but
that's for their specific purposes. They are not very keen on putting
stuff from others in it, if it doesn't concern the coding. And they shouldn't be
bothered by non-code essential things anyway; I'm sure they have better things
to do. But, that means ppl who have suggestions/improvements/ideas/or even
correcting simple spellingmistakes, are not really been heard, or nothing is
done with it, which, as I said, is a waste.
On the other hand, one can't give cvs acces to everybody
who merely aks for it; the more ppl, the more things can go wrong, after all
;-). And besides, since the cvs is not anonymous, some ppl may refrain
from using it altogether. A worthwhile concept thus, to have a webmaster with
enough authority to accept or reject ppls recommandations or suggestions; and in
doubt, he could still ask a third opinion, for instance, thereby reducing
randomnly crap-input.
One might see this as trivial, but I want to point out
that, since I got cvs access, I have already received some updates from a person
who didn't want to use cvs himself. I think with an official 'webmaster', easely
contactable, this would only be improved. It should be someone that is
reasonably trusted, volunteer, and has the will and the time to occupy himself
with it.
2)Seen the latest developments, one can not else then
deduce the stable/unstable branch gets mixed up to much. The system should be
structured such, that the unstabel builds are really only there for devl and
other geeks, to effectively test the stuff out, and only when there is agreement
that it has become really stable and usefull enough, should it be put as
stable.
It doesn't matter if the stable build doesn't get updated
in a long while: that's not it's purpose. It's purpose is, to offer a reasonably
working network (for the 'masses').
While this time between stabel and unstable may be
longer thus, in the future, I also suggest it should not be done NOW. I mean,
the current stable build is just crap, let's face it. The new (6226+) builds
seem to be much better. As soon as there is a concensus that it's reasonably
stable and working prety well (and I wouldn't wait too long with it), I would
put a build as stable. It will work better then the current stable build,
anyway.
3)for the sake of being user-friendly, one should set up
an edition-based index on the webinterface of freenet. I mean; we all saw what
happend to the DBRs.
now, evrytime I mention that, I get some negative
response, but I don't se really why. I mean, it's not that of a friggin deal to
put one lousy edition-index on it as well.
Some argue: but it's the bad network that is responsable
for the DBR's fall-out. Well, maybe so, but the network could have periods of
bad behaviour in the future, or the DBR maintainers could go on holliday, or for
some reason can't update, or they were busted by the FEDs or by the Chinese
secret police... I mean, the fact is, it's a point of failure. There are always
possibilities it's not going to be updated, and - wham - all usefull indexing
has gone.
And yes, the links of an editionbased index may go
old...but there is something like spidering, and a maintainer can find the time
to update it once in a month or so, now, can't he? and even if stuff gets
outdated: it still beats *nothing*.
All by all, I see no major problems or counter-arguments
NOT to set up (in addition to the DBRs) an edition based index, and quite a few
why it *would* be usefull. So, what you say we give it a try?
4)While I have given a try on the sponsor-thnk-u page
(seems not to have worked, but I can't see, because the cvs is b0rking), it's
beyond me to code for an auto-update of that page, whenever a paypal-donation is
made (and the donator selected/has chosen to be on the sponsor list, ofcourse).
I know some ppl have been sceptical about this, but I do think it would be a
nice feature for the website. Can Langley or Toad, *pls* do this? I've already
talked about it with Ian, so you can contact him or me for more details, if you
need it.
5)I'm not quite sure about this: but is there a debug-tool
being used (systematically)? I think I read somewhere a question about what to
use...well, can't the coders decide that? I mean, the benefit of having a tool
searching systematic for bugs would, even on the pretty-short term outweigh any
loss of time and energy that it took to actually implement it
properly.
I think it would be wise, after a reasonably stable build
is put on, that the coders should pause a while and first implement such a tool,
and then go on with the debugging.
|
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
