Just thought I'd start this up.
As per the agenda, we should target getting release 1.1 out as soon as possible. There is lots of good stuff waiting in the wings.
From the release 1.1 Planned features:
1. Sub-albums fully supported
2. Sub-albums for all included themes
3. Move/Copy/Rename images and albums online (without losing data)
4. EXIF viewing and theme functions
5. Image rotation
6. Completely redesigned image and album management
7. Options (zp-config.php entries) moved to web-based admin
8. RSS feeds
There are also a number of open tickets indicating a milestone of v1.1. We need to review these to see if any belong in the Planned features list.
It seems to me that #3 and #6 are the items without some kind of implementation. I suggest that #6 is not a requirement for version 1.1. The current admin implementation works even if it is a little cumbersome. I propose we move this item to v1.2.
#3 would be really appreciated by all users. I don’t think I am up to taking on the task, though. My learning curve would be too long for consideration for v1.1. Unless someone has an inside track on a quick implementation, I propose we move the feature to v1.2.
The only thing I would like to see regards #1 is an implementation of the Admin interface to set an album thumb to an image from any album. I’ve built the underlying support (and am using it in my theme—I used myPHPAdmin to set the thumb path.) I think Tristan has some good ideas for how this would work. Any chance for v1.1?
I think ticket #18--Disable comments. That seems to be on of the frequent questions asked on the forum. I have “disabled†comments from my themes by deleting the code.
There are a large number of open Tickets on the WIKI. Many have patches in the community build. What constitutes closure? Is it when we have a patch, or is it when the patch is in a release? I have gone through and assigned to myself those tickets for which I have written patches.
It would be great if the support team could go through this open ticket list and verify it the issue still exists. There are 18 “defects†in this list (many with patches attached.) What criteria do we use for closing a ticket with out a fix? I closed one of mine because it is not consistently reproducible. Can we close others that we don’t reproduce? In the end, we need a guideline for whether a “defect†needs to be fixed for a particular release. We might also want a guideline for how many outstanding defects we allow regardless of their severity. (We can always close trivial defects with the classic “works as coded†closure.)
Zenphoto
Comments
In your theme index.php file put the line:
`setOptionDefault('Allow_Comments', false, 'Set to enable comment section.', true);`
Then in image.php place
`<?php if (getOption('Allow_Comments')) { ?>`
`<?php } ?>;`
around the lines that produce the comment section.
Then you can enable and disable the comments from the Admin Options page. I suppose that these could be edited into the distributed themes.
#1 - I can do this interface before 1.1.
#3 - this is a must-have for a 1.1 release. It's been too long and it's a needed feature. Then again, we could push it to 1.2, because there's a lot in 1.1 that should get released soon.
I agree about the ticket list, we need to go through and organize. This is called 'triage'. We'll discuss more at the meeting, but feel free to organize in your spare time.
I have a few comments to bring up about the community build, but I'll sum it up in a general sense that it's not 'release quality' just yet. Of course, 'release quality' is up to the team, but there are many areas that need to be polished still, especially in the Options UI.
I have a list of issues I noticed while diffing the code in my merges. I'll go over some items in the meeting, but there are lots of small details.
A few things to think about:
1) Code style - try to emulate Zenphoto's original code: 2-space indentation, consistent formatting, comments, etc. If you copy code from another programmer and it's formatted wrong, please re-format it.
2) Design/UI style - same goes. I know most of you are coders, not designers, but try to pay attention to details. Use white-space liberally, it keeps things clean. In the UI, try not to overwhelm. Keep things simple and clean.
Basically, keep thinking 'zen' ;-) So far you guys are doing a great job and getting the features implemented, which is more than I could say for myself. But I just want you to remember that Zenphoto is not just about features - it's about features done as simply and elegantly as possible. Just something to keep in mind
Is there any formatter that we could use to clean up the code?
I don't know of any PHP formatters, though I'm sure they exist. Since I'm obsessed with such things I'm sure the problem will sort itself out naturally in very short time.
P.S. to all: Developer discussion is moved to http://groups.google.com/group/zenphoto-dev - our new google group. The forum will stay here for user support.
http://beta.chilifrei.net/wtf/configure.php
I am really not a programmer.. more of a hobbiest so I am sure it would need some code cleanup/tweaking, but its a start.. if you want the source lemme know and Ill email it to ya
Also had to obsolete some custom functions, as it looks like they've been integrated into the regular zenphoto function library. Excellent.
I'm off to read the transcript of the first meeting (sorry, new baby duties prevailed) so I'll catch myself up.
As soon as moving images from album to album (including subalbums) and uploading to subalbums is finished we will just about have a 1.1 release finished!!
actually, there wasn't anything broken. it was my effervescence theme. I'm not using the stock theme included in the build (i'm using my hacked up one), so I had to add pagination to the theme. I've not tested the stock theme with my gallery yet, but I'm going to shortly and will keep you posted. Has the Effervescence 1.1 been changed at all during all of the community build stuff? If not, I can post my changes for that theme after I get it tweaked a bit more. Cool?