Geeklog Forums

Really I'd rather just put up some dough and have you do it. That way we get a quality product and you make a few bucks.

I don't think holding it up for ransom is the right idea.

Maybe in addition to the Bounty have a donation button. I don't see any reason why you shouldn't get residual $$$ out of it too. If you have a PayPal account you could install the PayPal plugin and accept donations.

This too I've considered. If the current folks hold out and stick with their pledges I may do it this way. But in stages so (a) I don't have to do the whole project on spec, (b) It won't take 4 months, and (c) hopefully this would light a fire under the folks who bailed to re-pledge and I could do the whole thing without needing to ransom stuff.

Of course the big project: recurring events would not be the first part I did. I'm thinking about banging out categories. It's useful to most folks and should be the easiest of the three to do.

I wish a site like fundable.com had a 3 stage process. Their setup is a) post the fundable thing, b) receive funds when minimum requirements met. I'd like a version with a) post the thing, b) escrow the money when minimum met, c) release funds when thing is complete. The 2-step process works great for ransoms where the missing 3rd step won't take too long.

But that's what the bounty is. It just makes it so that more than just your cash is being put up.

Guys,

I am sorry to hear that my withdrawal has cause the project to stop. It definitely makes me feel guilty. I will stay in so that the project will continue, but let me be honest here.

The main reason I bailed out is because I think, since this is an important and complex plugin, it should go to someone with better experience and track record. I thought once it becomes a legitimate Bounty project, the best coder will be selected from those who are interested. Based on Dirk's comment here, it doesn't seem to be organized that way.

You know it is easier to bail out than sound rude. JM definitely knows more php and mySQL than I do, but based on my experience with using his previous plugin and support, IMHO, I just don't think he has proven that he can give us a quality product. Plus, he wasn't quite sure of his time availability, having to consult his wife, etc. I am just concerned. Maybe after using the Media Gallery plugin and spoiled by Mark Evens' outstanding and generous support, some of us just have been boosted in taste. It's just my opinion.

Maybe this is an opportunity for JM to prove his skills. I hope he won't disappoint those enthusiastic supporter of him, particularly Laugh. I am sure ttone would come back and contribute to the project if it is proven to be well developed and supported. Mark Evens developed his fantastic plugin for free, but people like us never fail to make contribution back to thank his generosity. Those who sow generously will reap generously.

I hope JM won't be offended by my honest concern. At this point I fervently encourage you to use the project to shine your skills and be the hero for everyone that has been waiting for this plugin for a long time.

Regards,

Sam

Hmmm. Well. This adds a wrinkle to the project that I had not anticipated. While I do not think any of this was necessary, I do appreciate your honesty. If you lack confidence in the basic ability of someone, I don’t think I or anyone else can legitimately demand that you have confidence.

JM has already expressed a willingness to produce the plugin and only asked that we sit tight. He accepted the task, told us we do not have to front the money at this point, and given us an idea when we might expect something. We could have just sat tight and seen the code quality for ourselves. I think rather than openly question a coder’s ability, it would have been far more constructive to get at what really concerns us, namely, getting out of the commitment if we are not satisfied. That is what we were trying to set up, a way to give the coder comfort that we are all serious, and a way to give donors comfort that they will not get shafted.

Samstone, I have accepted responsibility to look at the code and features. I would not release the money if I thought the problems were so severe that our wishes would be left unfilled. I came up with the feature list in the first place. So obviously I want them. I have also expressed a desire to have several other people join me in evaluating the plugin, to make sure I am on the up and up. You could be one of these if you wish, and that might take care of your concerns. Or, perhaps we could set up an arrangement wherein we give our pledge to a trusted source (such as tt0ne), with the idea that if we think the code is inappropriate, we could get a refund. I don’t think any of these are unreasonable. My concern is that we are having a coder with a family committing to considerable time and effort without any evidence at all of our seriousness. That is unfair. To make projects like this more common, we need a way to make this happen so that it is very comfortable for everyone.

I think we should all relax. I want to encourage everyone to recommit to your pledges and this time hang in there. No one wants to take your money or leave you with bad code. Work with us to develop a way to make yourself comfortable. If we keep working this out here, in the end we will all pleased with ourselves for finally making a calendar that works as it should.

Oh, come on, no one here will have the heart to let jmucchiello work for months and then tell him "sorry, buddy, it's not good enough, no money for you."

I mean, unless he ends up tricking everyone, no one will take his (yes, his) money away because the script works in 80% capacity and not in 100%.

I'm sure that's why samstone isn't willing to pay. He knows once he commits, it wouldn't be right to eventually not pay.

Oops! I didn't mean all of the dough but a contribution. Yes the Bounty, although I don't particulary like the word, is a good idea. We should really approach this like any other business endeavor.

What do you need to get started and what is your final $ amount (minimum for end product)? And when do you estimate having a working beta? How do you want to get paid, by Check, PayPal?

Reminds me of a saying - "Many hand make light work!", - get a lot of folks to pay a little bit is equal to or better than getting a few folks paying a lot. Hence the idea behind "Shareware".

I agree. We should respect the choice we make, the person we choose, and the labor he puts in. Once we commit, we should fully support JM's effort to the end, unless some really weird things happen. The opensource community is not a transactional deal, it is a transformational relationship.

Thanks!

Sam

Ok, Dirk mentioned he would handle the money, ttone hasn't been around lately so I assume he is out and I am going on vacation next week for a couple weeks so I can't really commit too it.

It sounds like we have enough pledges again but, we need to get the money in order before continuing.

- Dirk, we need your paypal account info.

- All funds are in US dollars

- Lets say we will collect funds till the end of August, if not enough funds are received, the first week in Sept the funds will be returned to all people minus any paypal charges, if there are any.

- jmucchiello said his minimum is $600 for the current feature set, once reached he will rewrite the feature set into a more readable form which Tex, myself and someone else?? will go over. Once we agree that all features are there and jmucchiello understands how all pledgers would like to see the features work we will give jmucchiello the go ahead.

- The plugin will be released under the GPL, the same as geeklog.

- Possible timeline - jmucchiello suggested that he can start work in August and hopefully get everything in by the end of the year. Of course if the money isn't collected quickly, etc.. this can be pushed back.

- I don't see this happening but if things don't work out during the coding and testing of the features then it would take the majority vote of the people looking after the Features (Tex, Myself, and someone else?) to either, disband the bounty or look for another developer. This 3 or so people would be in charge of the bounty and would have the final say on everything. Of course they should listen to the rest of the people who pledged money. This process could also be done via a majority vote of all people who pledged money but I think if we get to many people involved in decision making it will take too long.


I think I covered everything, If you have any suggested changes please voice them now so we can discuss. Once Dirk gives us his paypal info and we have made a final decision on how decisions are to be made regarding the bounty I will submit my pledge.

---

One of the Geeklog Core Developers.

For the account name, please use the email address that you can find in pretty much every Geeklog file: dirk AT haun-online DOT de



If I'm reading PayPal's terms correctly, then a full refund, including any fees, can be given within 60 days of the payment.

Please add "Calendar plugin" and your geeklog.net username as the subject / reason so I can track the payments.

I'll post updates here.

bye, Dirk

Here's my task list. There are a few outstanding issues here. I don't know if this is the right thread though to discuss them. Let me know if I've missed anything critical.

1. Event RSVP
   • Modify event edit/create screen with checkbox: "Allow members to RSVP for this event"
   • Issue: What about recurring events? If the event is an 8-week class, you should RSVP for the whole 8 classes. But if the event is a monthly gathering of friends, you should RSVP each gathering separately. So the checkbox becomes a dropdown box: "No RSVPs", "Accept RSVPs on Master Event only", "Accept RSVPs on Individual Occurrences only", "Accept all RSVPs"
   • DB change: event table: Add field AcceptRSVP
   • New Table: event_rsvp (eid -> points to event, uid -> points to user table, response -> key of associative array)
   • Modify event display with an RSVP field/area. If you have not indicated your RSVP status this box contains the dropdown "Will attend" or "Will not attend" and a submit button. Contents of dropdown is based on an associative array: Array(1 => "Will attend", 2 => 'Will not attend")

     If you have already attended the dropdown will display your current indication (with text like "Your RSVP of "will attend" is already recorded") and the submit button becomes a modify button.

   • Suggestion: What about attendees not signed up to your website? Can anonymous users RSVP? More important is if you want to know how many attendees there will be can people bring guests? Again a class event wouldn't have guests but a company picnic where your users are employees would need somewhere where you could say you, your wife and 3 kids will attend. After all, if 30 people RSVP the company picnic you don't know the true head count.

     For that reason and because it doesn't take much effort I suggest something like the evite.com model: Include a "# of guests" field and a "remarks" field so people can leave comments.

     This means we now have "Allow members to RSVP for this event", "Allow members to bring guests", "Allow remarks"

   • Modify event view to show list of RSVPs and their attendance status. (Note: the original requirements for this was two section for will and won't attend but since the response list is expandable I think this cannot be "two" sections.
   • Suggestion: Allow attendance lists to set to private (only the owner of the event sees them) or public (anyone can see who is attending).
   • DB Changes for Suggestions: Event: AcceptRSVPs TINYINT(3), AllowGuests TINYINT(1), AllowRemarks; EVENT_RSVP: attendees SMALLINT(5) DEFAULT '1', remarks VARCHAR(255)
   • Issue: Anonymous attendees? I'd say no but I'm sure someone will want it.
2. Event Reminders
   • Modify event edit/create screen with checkbox: "Allow members to be reminded of this event"
   • Corresponding DB change: Add fields AllowReminders TINYINT(1) UNSIGNED NOT NULL DEFAULT '0'
   • Issue: Again, recurring events means we need to differentiate when you would subscribe to the master event or individual occurances or both.
   • New Table: event_subs (eid -> points to event, uid -> points to user table, send_date -> next time reminder will be sent)
   • Modify event display with a Reminder field/area. Area will be a field of check boxes with various remind me tags: "Remind me two weeks before event", "Remind me one week before even". Users can check any or none of these reminders. List of reminders will be configurable as an associative array.
   • Cron job and Geeklog scheduler job for sending reminders. Content of email will be template driven just like the GUI.
   • Issue: Should the list of reminders be visible to the admin/owner? Should the admin be able to reset the existing reminders?
3. Category Calendars
   • Create a category create/edit screen. Categories have 4 fields: Name, Description, Is_enabled, Style, as well as full permissions
   • Create a category list screen. admin/plugins/calendar/category.php?mode=list
   • New Table: event_cats (cat_name, cat_descr, is_enabled, style, ownerid, groupid, permowner, permgroup, permmember, permanon)
   • Modify event create/edit/submission screens to include category dropdown. Dropdown would include dummy category for no category called "Master Calendar".
   • Modify all views with dropdown list of categories. By default category is master calendar and views show all events. If dropdown changes to a specific category only events in that category are shown.
   • Style field is used to color code events on Master Calendar view. (When view is category specific, events use the default color.) I figure the full CSS style name is easier here rather than just color numbers for maximum flexibility.
   • Suggestion: Use a dummy category: "personal" to switch to personal calendar. This way the dropdown box takes up the screen location of the "switch to personal view" text now.
4. Recurring Events
   • Modify create/edit screen with a recurring area. Area contains various fields to allow specification of recurrence.
   • Modify event table: Add RecurringData field as VARCHAR(255). Contents of that field will be a set of tuples describing the various recurrence patterns.
   • Explanation: the varchar will contain something like '(and: (weekly: M,W,F),(monthly: T2,TL))'

     weekly: accepts list of days (M,T,W,H,F,S,U) Days can be followed by *2 or *3 to indicate every 2nd or 3rd that day.

     monthly: accepts list of days where the day by itself means every week on that day. Day can be followed by 1,2,3,4,5 or L mean the 1st, 2nd, 3rd, 4th, 5th or last occurrence of that day in the month. Monthly can also take specific number 1-31 as well as L and L-1, L-2, etc.

     yearly: accepts a list of dates in MON ## format (Jan 1, Dec 31) or WEEK ## D (week 16 M)

     list: accepts a list of dates in YYYYMMDD format (20070801,20070809,20070820) Events only occur on specified dates

     daily: accepts a number as it's list and the number is skip period so by default it is 1.

     Other examples: (weekly: M,T,W,H,F) (weekly: S,U) (weekly: M*2: start=20070820) (monthly: F2,F4) (monthly: 1,15) (monthly: 15,L) (yearly: Jan 1) (yearly: Jan 1,Apr 1,Jul 1,Oct 1) (and: (weekly: M*2,W*2,F*2: start=20070820),(weekly: T*2,H*2: start=20070827))

     Modifiers such as start= allow for stuff like every other Monday. The date after start tells you which Monday it first occurs so you can find every other Monday there after.

   • Recurring field will be fully extensible through an API.

     The code will have event_recurring_weekly and event_recurring_monthly style functions so to handle unusual recurring needs. Stuff like holidays based on lunar calendars (Easter, Passover, Ramadan). Implemented correctly, I can imagine someone making events selectable based on a non-western calendar.

     Another example would be something like event_recurring_usholdiday which defines all the federal US holidays and allows you specify events based on those key words. They don't even have to be recurring at that point. (usholiday: thanksgiving)

     The event_recurring_xxxx function will return various things depending on its inputs. One mode would be to return a partial HTML form (hopefully using a template) so users can create an event of that type. Another mode would be to parse the form data into the above tuple format. A 3rd mode would take the tuple and a date and return the next occurrence of that event. Other modes may be needed but those are the main 3.

   • Types of recurrences handled out of the box: Annual, Monthly, Weekly, Daily, Business days, weekends, specified days of week, specified days of month, specified days of week of month. Combinations thereof.
   • New Table: event_instance: This table contains a record for every instance of the event.
   • Issue: Original spec specifies a "recurs indefinitely" checkbox. This does not work with having an instance table. Personally I don't see why someone can't just set the end date to 2020. What is the real lifetime of these web databases? Note though that I will not implement such a feature as it hinders the rest of the design.
5. Other Tasks
   • Modify plugin_install_calendar and plugin_uninstall_calendar
   • Support MSSQL. Note, someone will have to help out with that as I don't have a MSSQL database to test with
   • Personally, the personal_events table is redundant. It should be folded into the main events table to simplify queries and calendar construction. Likewise, making a personal_event_instance table to handle recurring personal events would be tedious to code.

If no one objects, I hope you'll even let admins add reminders (that way, an admin could create fake users just to send reminders to people).

Also, will you have a snooze feature? Something like "here's your e-mail reminder. Click on this link to be reminded again in X time." If not, at least you provide a link to the edit the event.

As a one-off reminder, I suppose that could be added as a bonus feature. I don't like buttons that let people spam their users.

Similarly, I wouldn't allow anyone not logged in to subscribe to a reminder. This is so your system cannot be used to spam someone.
The reminder will be a standard template with a bunch of standard fields. You could easily construct a link to the edit event screen as worst case. Adding a snooze sounds simple and I could add it as a bonus feature. But unless it's a deal-breaker for you, let's leave it off the official requirements list.

jmucchiello, I did a quick skim of your points, looks good. I will do a more detailed review early next week when I have some time (and on vacation)!

Regarding Recurring Indefinite Events. The end date idea is the way to go. Maybe a config option in admin so if changed, all recurring events will get updated.

Tom

---

One of the Geeklog Core Developers.

What do you mean by "one-off"? When you say "people", do you mean admins (who can just mass mail)? It just means that I can send reminders without forcing people to register themselves.

I mean the admin would be able to send, not a reminder, but a notice. The admin wouldn't choose for it to go out 1 week before or 3 days before the event, it would go when the admin clicked the button.

Such functionality is not in the original post and that's why if it gets done, it would be a bonus feature.

I wish you'd let the admin just subscribe users to reminders, just like the admin can sign them up for groups. Not everyone is a power user (or: sometimes people want reminders from you, but you can't tell them to do it themselves).

Now look, I know everything is possible with coding but these two activities are not related. This is not me allowing or disallowing. This is me stopping feature creep. A line has to be drawn somewhere. This feature is a whole new screen: new form, new code path, and creating the list of users probably has a javascript component. Ask for it after I'm done.

I think the plan is good. And just like all things Geeklog there will be enhancements and changes in the future.

I am interested in contributing to this effort. I can add $300.00 but I need to have someone explain the update to me. I want to know if I can use the same fields as I have in my calendar at www.iantiquesguide.com and add recurring events as well?
Thanks,
Jack

Go to the first page of this message. There are links in the first post to three other threads that detail what's being done. My post above is just a summary. Your site seems to be running the standard Geeklog calendar plugin so, yes, this will be an upgrade to your existing calendar once it is finished.

The short answer is a group of folks are putting up a bounty for several enhancements to the core Geeklog calendar plugin. Those enhancements include recurring events, RSVPs, reminders notices, and the ability to separate events into color coded categories. I am the programmer taking up the bounty. And I've given a soft commitment for an end-of-year date of completion.

Your additional contribution is much appreciated and will make scheduling my time (against my wife's moods) even easier.

Method of payment details are still be ironed out so just pay attention to this thread for more details.