-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> That's totally true, but couldn't we have some sort of open list, where
> all the tasks get listed by people that want things done. for example,
> the good folks working on the java side might need help with imaging or
> someone else might need some of the man pages edited.
We have that list, two of them. plucker-dev, and plucker-list.
Creating more lists just creates more confusion when people want to figure
out where to go to find what they are looking for, and increases the number
of lists we (as list subscribers) need to join and read and manage. I don't
know about you, but I'm already getting ~400 emails a day. I don't need to
read any more.
> everyone in the community could vote on its priority, which should help
> guide people on where to start.
As much as this project benefits the community, we can't let the
community drive the features of it. If we did, it probably would never have
worked on Linux, and would have been ported to WinCE 2 years ago. We have
goals of our own, as well as those people who have "wish list" items for the
project (myself included). We are just trying to provide something everyone
can use.
That being said, it's Open Source, you have the source. If it
doesn't do something you feel you need or want it to do, just add it. if you
think others can benefit from those additions, make them public and
contribute them back to the community. If they're worthwhile and don't break
the existing platforms we support, or the existing application and toolset
itself, they're very likely to be considered for inclusion into the core
project itself.
Clan Coding is bad, and no amount of villagers with pitchforks and
torches outside the door is going to make the project do something it wasn't
intended to do.
> one rabble could administer it collectively... simply to filter out
> profanity and complete rubbish.
Someone could certainly create an _offsite_ list, but again, that
fractures where people go for information. These two lists are fine, and
have worked for us since ~1998/1999 timeframe, without much problems.
> in essence, any sort of central management is out, but the open list, just
> with a list of todo's might help casual helpers find where they can help
> out most.
I have an even better idea. Much like the Linux Kernel mailing list,
or the Perl mailing lists, delegate the "gatekeeper" and moderation to
others. If you're interested in keeping track of what needs to get done,
just patiently read the list messages, and keep a notepad handy, and write
things down.
I elect you, to keep a running tally of the outstanding TODO items,
and when people wish to contribute, section them off to them, and see if
they can help achieve them. I'll give you a short list of things to work
with:
1. Add more "Tip-o-the-Day" items to Plucker Desktop (Robert has
already mentioned where these are and where to find examples)
2. Go through the existing TeX documentation and find the missing
bits, broken pages, areas where graphics need udpating, etc. I
don't have the time to do it right now, but I will soon. The more
"up-front" work someone can do to help me, the faster I can
work.
3. QuickStart/HOWTO documentation for each part of the project
a. Plucker Desktop Usage
b. Configuration and Installation (parser/viewer)
c. Commandline use of the parser
i. Using 'raw'
ii. Using [BlockName] blocks in ~/.pluckerrc
4. Manpages for Plucker Desktop, plucker-build, unpluck, explode
That should get most people who aren't "coders" started. There are
other tasks for coders as well, but the ramp-up for them, is getting the
right build environment set up and configured for their use.
> this will build into more dedicated contributors and eventually, better
> developments? ... faster releases? ... an even better community spirit?
Releases are based on finding bugs, closing them, and providing new
features as required. The only way to speed that up, is to get more people
testing it, and providing feedback faster.
If a project takes 1 year for one person to complete, would it then
take 3 months for 4 people to complete? 20 minutes for 50 people to
complete? These things don't scale linearly as you would think they do.
There's a lot of coordination involved with making a release, and the amount
of other ancillary tools and parts we all work on and maintain must all work
together, before we can release it as a completed version to the public.
> you should never tell anyone what to do... they can just pick off what
> they want to do or even add another suggestion for a task.
Keep the tasks within scope, or they'll never get done.
d.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.92 (GNU/Linux)
iD8DBQE9kGp2kRQERnB1rkoRAudyAJ9KNX46ewPUwuzCsa0s1UQEf8SE+gCgsfHs
9CsI3KZpkAWiVw0fmgVhvoc=
=ROgv
-----END PGP SIGNATURE-----
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
