[geeklog-devtalk] Re: [contact-us] Groklaw & Geeklog

[Tony Bibbs]

Andrew,

I am forwarding your note to the geeklog-devel mailing list.  This is 
the list that you can use to email the entire Geeklog team.  We are glad 
you are looking to add some high-volume features to geeklog.  My name is 
Tony Bibbs, I was the day-to-day manager of Geeklog 1.3.x branch once 
upon a time.  That branch is now maintained by Dirk Haun (I'm presently 
working on the pitifully slow development of the 2.x codebase).  Dirk 
would be the primary point of contact for you moving forward.  I have 
attached my initial input below but please, and I'm sure Dirk will give 
some input as well.

Andrew Dyer wrote:


> G'day

>

>You may be aware that Groklaw (www.groklaw.net) is using Geeklog. Groklaw is a high volume site (with it's own Slashdot effect) and allows comments on all articles posted by the editor (Pamela Jones). Anonymous posts are also allowed. It is not uncommon for there to be more than 250 comments per article and a large number of these are generated in the first few hours. A number of the regular contributers at Groklaw and PJ have identified some changes that would be advantageous to the site and have just formed a project to implement these changes.   I am writing to you as the initial project manager for this team, to let you know of this and ask for some information from you.  Our intent is not to fork Geeklog, but to rapidly develop features that are probably more important to us than to your regular users. We will probably set up a project on SourceForge, but it's only output will be the hacks and plugins developed.  We would very much like to work with you to merge these into the main codebase if they seem worthwhile to you.  It is only in the planning stage and no coding has been performed. Listed below are the main enhancements we have identifed along with PJ. 

>

>   1. Allow individual comments and threads (comment children) to be hidden (and unhidden) by moderators

>   2. Allow Articles and individual threads to be locked as read-only. This should be performed automatically after 3 days, but manual locking  should be an option too. Capability must be provided for an admin to unlock content also. (moderators)

>   3. Allow user accounts to be locked permanently or temporarily by admin

>   4. Prevent anonymous access to member information

>   5. Allow individual comments to be "modded up" in such a way that  they appear (perhaps) as a list of links straight beneath the main article (logged in users)

>   6. automatic linkification (which I note is actually in the latest release candidate)

>

>To this end may I ask some intiial question of you. I'm sure there will be more...

>

>1. Is there a field in the comments table that I could use to encode (bitmask) 4 optional attributes? If not, what is the chance of you adding a "status" field to the official comments schema? The status would use bits 0-3 of a byte field, with 0 being standard (default behaviour), decimal 1, 2 and 4 representing other statuses - some mutually exclusive, some additive. Obviously, if accepted, we would have to document what each bit represents. The same sort of thing might be needed in the user table (ie a user status field)

>  

>

Such a field does not exist.  Adding one wouldn't be a problem.  I would 
recommend arbitrary bit values and, instead, go with a look up table 
that better explains what each value really mean.  Again, I defer to 
Dirk's judgement...that's just my two cents.  Regardless, it's a great idea.


>2. do duplicate functions in lib-custom.php automatically overide those in other libraries (specifically lib-common.php)? If not, what mechanism would be recommended to overide the comments output and administration? Is the only way to do this with a direct hack to lib-common.php and others? Or  would a plugin achieve this?  How would *you* go about implementing enhancements 1, 2 , 5 and 6 (for example)  whilst maintaining maximum compatibility with any new version of Geeklog?

>  

>

All of your code changes should be put into lib-custom.php.  If you wish 
to override the default behavior of the core functions in lib-common.php 
I would first ask that you discusss which one might make sense to be 
included in the core code for everyone's benefit.  For anything that is 
truly custom, I would put them in lib-custom.php and simply comment out 
the methods in lib-common.php.  If you document your lib-custom.php 
closely this should make migration fairly straight forward for you.  
Items 1, 2, 5 are probably things that can be worked into the core 
codebase (again, Dirk would be the final point of contact).  Item 6, as 
you noted, is already addressed in CVS.


>With one (1) above I could of course create another table linked on the comment id, but I was hoping to avoid another join for performance reasons and I want to stick with the officially supported schema if at all possible.

>  

>

Understood,  Again it is a good idea and I'm sure we can come to a 
suitable solution that makes everyone happy.


>Finally - are any of these enhancements actually in the latest RC or in development? It would be silly of us to re-invent the wheel.

>  

>

Dirk can better answer this than me.  I think only item 6 is covered 
already.


>If you feel uncomfortable about answering these question based on a random email, you can check with Pamela Jones as to the validity of this project. Her email address is pj at groklaw.net. Alternatively, the webmaster is mathfox at groklaw.net.

>  

>

Nah, I think this is a great experience for all of us.  Is shows how a 
truly collaborative and open piece of software can change to meet the 
needs of those who use it.  I want to let you know (and I'm sure I speak 
for everybody here) that your note was a breath of fresh air and showed 
a tremendous amount of tack.

We recognize just how important Groklaw's work is to the OSS movement 
(most notably keeping an eye on the SCO situation) and knowing that 
Geeklog is a part of it (no matter how small it is) make all of us who 
have been involved with Geeklog feel good about the work we have done 
and it makes clear how things can be made better moving forward.

I would recommend, if possible, that you lurk in irc.freenode.net in 
#geeklog.  My handle is IA-Outdoors, Dirk's is dhaun and the other 
notables are Vincent Furia (vinny) and Blaine (Blaine). 

I'm guessing the best way to proceed would be to have Dirk to confirm 
that the items you want aren't already in the works and for him to work 
with you on how to implement each feature.  From there you'll be free to 
do what you think needs to be done and submit the subsequent patches 
(Dirk may even be willing to give CVS commit access after the  first 
good submissions come in ).

--Tony