Re: looking to volunteer my services

>>>>> "DR" == Dave Rolsky <[email protected]> writes:

  DR> I was thinking that these could all be just 'categories', in sort of a
  DR> tree system:

  DR>  Technical -> Programming -> Perl
  DR>  Technical -> Programming -> Regular Expressions

and which does MRE fall into? that is the problem with trees. multiple
attributes cover that.

  DR>  Fiction -> Erotic -> Furry fan fic (yeah, gotta have lots of that ;)

sure as long as it has lots of perl content too. :)

  DR> Expertise level would probably be a separate (and optional) attribute.

  DR> The problem with the multiple axis method you're suggesting, IMHO,
  DR> is that it requires us to be adding new axes on a fairly regular
  DR> basis, because existing axes won't be suitable to new types of
  DR> books.  The axes we use for programming books aren't necessarily
  DR> appropriate for fiction which aren't appropriate for non-fiction
  DR> historical books etc.

i agree that adding axes forever is not good. but we can come up with a
reasonable fixed set of axes. northern light did it with their
cataloging of web pages. also we will not be allowing all books in the
wordl on so we can limit out axes and categories somewhat.

  >> i am agreeing to that. can't you read?!! :) i said popular with the perl
  >> community, not necessarily a perl book. just that all perl books get in
  >> no matter what as it is the PERL community books page.

  DR> Ah, I see.  But why would the committee ever reject something is
  DR> my question.  Besides weeding out duplicates, which may not be a
  DR> big issue with a decent search engine.

i don't want to see any random book get on the page unless it has some
interest to/from the perl community. if several people recommend a book,
then it should get in. maybe the foe/friend system could be used or some
other voting thing. like a minimum of 20 votes with 75% yes will get a
book in. the cabal can override any vote (just like the NFL referees :).

'furry fscking with perl' gets in no matter what. 

i just want to keep this focuses on our community and not allow useless
books to clutter our db. it should be easy to browse this site by
category and if we get tons of $OFFTOPIC books, that will make it a
pain.

like i said, many computer but not perl books or others of real interest
to the community will get in. some fiction will too (tolkien for sure,
jackie suzanne will not).

here is a possible scenario for submitting a book:

	someone fills out the book submission page. this gets the usual
	facts (maybe just isbn can be used to slurp the facts from
	amazon :). this is announced to the books list (this list or
	another?) and put on a submission page (maybe the front page can
	have a submitted section). reviews are linked to it and the
	submitter can write some lines as to why they think it deserves
	to get in.

	signed in users can vote and there is a 1 month time limit on
	this. if we get a minumum of 20 votes and 75% are yes then the
	book is inserted into the DB and announced

  DR> Or, on reflection, we could store some 'books.perl.org'-specific
  DR> info locally as well.  Hopefully we'll be able to pull ad-hoc user
  DR> info from use Perl as needed for display on books.perl.org.  At
  DR> least that's what Chris Nandor and I were theorizing about.

whatever. i will stay out of the user login stuff for sure.

  DR> Here's what I see as being the next things that can be worked on.

  DR> - UI design.  sfritz volunteered for this.

good! we found a sucker^Wvolunteer. :)

  DR> - DB design.  This is partly there but may change depending on how
  DR> we decide to categorize things.  So let's talk about
  DR> categorizations.  Other than that, I think what I have is fairly
  DR> good, and I don't see a lot of debate here since its just a small
  DR> number of tables and this isn't rocket science.

well, i stated more of my view above. i think we need another thread
just on that. this email covers too many subjects as it is.

  DR> - use Perl integration.  Basically, use Perl (i.e. slashcode) needs some
  DR> sort of machine-usable interface for doing the following:

  DR> -- Given a username/id/something and a token, saying that this is or is
  DR> not a valid token.  Presumably, this token will be set by the use Perl
  DR> login mechanism as a cookie for the 'perl.org' domain, so we'll be seeing
  DR> it at books.perl.org

  DR> -- Given a username/id/something returning relevant public user info.

  DR> Then we'll need a client-side piece for this as well, which should cache
  DR> things heavily so as not to beat the crap out of use Perl.

  DR> I can work on this but not right now so if there are any volunteers I'd be
  DR> happy to help in a mentoring way, but writing large chunks of code is out
  DR> for the moment.

we had people a while back (yapc time) looking to do work. are any of
you still around? could we post back to use.perl and get some of those
who were in your thread to do some work?

shirking work here,

uri

-- 
Uri Guttman  ------  [email protected]  -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org