Things to do

The first list is the only one that is currently active. The other lists are mostly things that are "nice to have" or things that sound nice, but aren't going to happen.

Note that it is possible for items to move between lists.

If you have comments or suggestions, let me know at support@letshelp.us.

• A user name with an embedded space doesn't show up in the password file. I cannot replicate this, but keep your eyes open. This may have been fixed earlier. I expect that other places will have problems with embedded spaces.

Ideas for future consideration

• Features for billing.cgi.
  • Make PayPal payment online. This should automatically record the payment. Intercept email and process. Watch for the amount being changed. Log the comment. [needs additional information]
  • Use the automated PayPal interface at: http://www.paypal.com/cgi-bin/webscr?cmd=p/xcl/rec/ipn-techview-outside
    This requires all transactions to go through this, so it isn't appropriate until we get a separate bank account for this application. [needs additional information]
  • Get a real merchant account besides the PayPal account. Check with our DNS registrar. [needs money]

• Features for calendar.cgi
  • Define needs. Allow tasks to show up. Perhaps other things as well. Treatments, appointments, etc. [hard]

• Features for email.cgi.
  • Allow sending HTML email. Re-enable HTML and photos in the configuration pages. This involves generating a MIME multipart message. It also means that people should have a choice if they want text only messages. So if the user wants text only, the content must be simpler then for other recipients. [hard]

• Possible discussion forum.
  • Have a site wide discussion forum and knowledge base to allow users a place to discuss issues. Possibly have different forums for different sorts of problems (e.g. how to use this site, cancer issues, etc.) [hard]
  • Have a site specific discussion forum. This should be done once appropriate forum software is obtained or written. [medium]

• Features for guestbook.cgi.
  • Have an (optional) guest book available on the main page for each user. This can be based upon my current guestbook package, but needs to have ways for coordinators to add responses, and for coordinators to edit and delete entries. [medium]

• Features for login.cgi.
  • Allow a user to delete their account even if they are simply receiving email. We could have every message be individually addressed with a security code in a URL that when clicked would delete a specific account. Needless to say, this is sort of weird. [medium]
  • Add a sidebar item to toggle administrators between volunteer view and normal view. Store the state in the profile. Change IsAdmin (with the exception of the toggle) to report the current mode. [medium]

• Features for photos.cgi.
  • Show which files refer to each of the photos. We have news, requests, description files, etc. Use a cache file for each of the categories. [medium]

• Features for request.cgi
  • Specify the number of people who can sign up for an item. There might be two categories (responsible and helper) [medium]
  • Sometimes people will be willing to work on a project, but not want responsibility for it. How can this be represented? A general comments field that anybody can write in? Some way to signup but not be responsible? [medium]
  • It'd be nice if a coordinator could claim that they originated a request even if they didn't. It'd be nice if a volunteer could pass control of a task to another volunteer. [medium]
  • Allow for recurring requests. [medium]
  • List accomplished requests and offers for an individual so that people can be thanked appropriately. Show dates, and link to the appropriate item. [hard]
  • Bulk add requests. The data will need to be checked out carefully to ensure that they aren't doing anything nasty. [hard]
  • Have a way to have a task that people can accept and complete, but doesn't block others from accepting and completing it. Record that they did so. An example might be "Call Ken and tell him that smoking is rather stupid". [hard]
  • Allow for hierarchical requests where people can agree to a portion of the request. [hard]

• Features for search.cgi
  • Search in authenticated pages. News and requests. Link into user page. [medium]

• Features for signup.cgi
  • Have a black list for IP address ranges where abusive behavior has been noted. These addresses cannot create accounts. This set of addresses needs to be editable. [medium]

• Features that have wide spread ramification
  • Make it obvious how to do a news only site. Then have a way to turn on the task assignment module.
  • When we tell people that their free time is up, have a mechanism to say "I don't want it; make it go away" rather than just timing out.
  • John would like more graphics.
  • Make the current sidebar item stand out. Either make it not a link, or bold, or something. [medium]
  • Use icons in places that need attention. [medium]
  • Remove host name from URLs where it isn't required. This will make it easier to test under alternate domain names. [medium]
  • Force distribution of a new version through all of the sites. [medium]
  • Use CVS to deal with versions. Add the various rules for "make status", "make update", etc. Have a configuration program or something to do the localization. Remove old RCS repositories. [medium]
  • Register as a DNS server. [easy]
  • Transition to http://SITE.letshelp.us/. Allow a www before the site name. The bad.url.cgi can help here. Put wildcard in the DNS. Given the wildcard, can we override specific entries in the DNS space? Need wildcards in apache as well. The goal is to make URLs shorter, and potentially have different sites on different IP addresses if we want to instantiate DNS information. [medium]
  • Use a real indexer to support the searches. See dig. [medium]
  • Mod-perl [hard]
  • Look for performance bottlenecks, and improve them. [hard]

• Items that need outside review and updating.
  • Rewrite tutorial (Template/tutorial.wc) to make it clear, concise and understandable. Ensure that all of their options are covered.
  • Create favicon.ico to keep from cluttering up the logs.
  • General flow of work.
  • Build a tri-fold brochure
  • Build business cards
  • HTML conformance testing.
    w3c.org, bobby.
  • Resource list of places to deal with different classes of care. Cancer, Dementia, etc. Build an appropriate library for people to draw upon. webc.src/ref.html

• Link to tasks

• List colors/shape

• conditional menus

• Icons for actions
  • agree
  • complete
  • edit
  • delete

• forward to a friend

• put "add request/offer" on all sub pages

• Show all users + details

• News -> title, summary, read more

• How do you have many coordinators posting?

• Need more color differentiation on different segments

• What if the task takes 3 people?
  

  For example, the uu-social-concerns lunch has a bunch of tasks.

  This happens every month.

  A) How do you represent all the items below
  B) how do you do them all again without retyping them?

  ACTION LUNCH PLAN
  

  • Date April 4
  • Coordinator 1 person
  • Beneficiary: 1 person
  • Tickets: 1 person
  • Publicity: 1 person
  • Speaker: 1 person
  • Soup: 3 people
  • Sandwich Fixings: 1 person
  • Bread for Sandwiches: 1 person
  • Veggies: 2 people
  • Fruit: 2 people
  • Cookies/Dessert: 3 people
  • Set up: 3 people
  • Clean Up: 4 people

Blue Sky and Things that didn't quite work out

This section lists ideas that didn't pan out, or might be nice in some different implementation. This shows we thought about it and decided to not move in that direction.

• Features for login.cgi.
  • In the login box message, indicate that their ID is likely their email address.

    I don't see how to make this happen with the standard password mechanisms. Doing session management/cookie style passwords might make this doable. But I don't like that direction.

  • Users can see the email addresses of people who have taken ownership of requests, and users can send direct email to these people, but users cannot see the list of all users, nor can they see the user profile to see if it is the right person they'd like to send email to.

    This would be straightforward to implement. It would have the benefit of people making direct email contact to self-organize implementation of a request. It has the drawback of exposing people not only to the person they are trying to help (or the other coordinators), but also to everyone else willing to help. At this point I'm going with the privacy. If this is implemented, it should be selectable by the coordinators.

  • Change the logout procedure.
    When someone logs out, record a record of their request with time, IP address, and browser string. All authenticated programs call a logout routine before printing html/text that can give a 401 error if it is appropriate, causing the browser to lose it's user/password for the realm. Once the bad password error is given, the record of the logout is removed. Give a bad password error if IP and browser string match. Note that because several people could be using the same user/password, and they all could be logging out, there needs to be a set of logout requests. This will still not be perfect for places where a single computer can show up under different IP addresses (DHCP or different gateways), or where multiple computers that are configured with the same browser but sharing a gateway and user/password. There are enough edge cases that this is likely to be hard to get reliable without using cookies.

    Another thought. If we have noted that someone has signed out, then we can redirect them to the member page with a redirect rather than a 401 error. This still doesn't get rid of the browser's idea of the realm though. They also need some mechanism for logging back in.

    Another possibility is having a logout directory (like we do), and having a logout link carry the new user/password to auto login such as:

    	  	http://logout:logout@site.com/logout/
    		

    I seem to recall that this may be removed in current patches of IE. Check that out. It seems that Netscape doesn't deal with this either.

    Note that the apache documents indicate that you can't do a logout using browser authentication.

    Setting a cookie (even a non-disk based cookie) will resolve all of this. At the start of every authenticated CGI program you check to see if the cookie is available. If not, place one there and say they are authenticated. If the cookie is there, see that it is not on the canceled list. If it is canceled, return 401 and clear the canceled status. The cookie can be something nominally unique like the IP address and time.

    However, the short answer is that you can log in as another user, and if you fail to log in the second time, you are effectively logged out.

• Features for email.cgi.

  • Authenticated users can send email to the coordinators, but not send email to all of the members of particular groups.

    This would be straightforward to implement. However, I am trying to keep the level of email noise down, and thus limit sending email to groups to the coordinators. If implemented, make it one of the site on/off features.

  • The email address that represent groups cannot be accessed from standard email.

    This could be implemented. It'd either require integration into a standard email list manager (e.g. majordomo or mailman), or just have our own gateway. This would require access to a file used by the SMTP aliasing structure. These addresses would then be open to the spammers unless we do the check "only email addresses on the list can send email to the list". Integration into one of the standard packages has benefits and drawbacks. mailman has an email archive, but it also has its own authentication scheme which would need to be dealt with.

    All in all, I think the hassles of SMTP email to the groups is not worth the effort.

• Features that affect all of the "Let's Help" sites

  • Have a library of templates for the look/feel.
    This should be changeable on the fly.
    The user content should be include files.

    I am not sure how I would pull this off with the sort of templates that I have. Maybe more thought would get this on the list again.