-
Notifications
You must be signed in to change notification settings - Fork 60
Roadmap
Target: end of August 2015
-
add ability to take payments for events
-
fixed and suggested donation amounts
-
new RSVP workflow to include payments, receipts, possibility for tax-deductible donations?
-
new cancel workflow to include refunds where necessary
-
provide mechanism to clarify event cancellation policy, esp. WRT payments (on the model? per event? how to enforce?)
-
new event manage page to let organizers and location admins manage event and RSVPs
-
payouts to communities for events
-
event payment tracking page, analogous to reservation payments
-
may also necessitate a new manage page for payouts (across events and reservations)
-
unrelated items for events that may get rolled into this work:
-
ability to message event attendees from event manage page
-
event comments
Target: end of October 2015
Support for defining and managing custom membership offerings per community.
- new manage pages for creating, viewing and editing memberships types
- new manage pages for creating and managing individual memberships
- managing failed payments, re-submitting payment, canceling or updating membership types
- automated recurring membership payments (celery tasks)
- membership payments summary page for community admins
- profile page access to viewing and managing your own memberships, payment history and payment confirmations.
- policies around creating new and canceling memberships (admin-managed to begin)
- potentially create ability to have multiple credit cards on file for your profile?
- on-site sign in page
- tracking sign ins?
- extend auto-generated email lists to incorporate members. members@ list, everyone@ list to cross multiple groups?
Target: end of October 2015
Group reservations are very awkward currently. Several communities frequently have to deal with this by manually making reservations under admin accounts and finagling the bill onto one of several reservations while comping the rest. It's time consuming and also confusing from an occupancy analysis, billing and communications standpoint.
- ability to create and manage multiple reservations under one bill and one coordinator account.
- workflow to expose this option, either through primary reservation workflow or a distinct group reservation workflow.
- will require a new view for group billing and access to editing reservations (the manage page is fundamentally designed around a single reservation).
- will require distilling the "user" of a reservation from the "creator." managing permissions on reservations and billing information accordingly.
Target: end of November 2015
Moving towards a model that emphasizes individual branding over the network. This is a planned to happen a little later because we'd like to do it in line with the new landing page and design (below), otherwise it may be confusing with the network nav bar at the top.
Currently we support redirects from example.com to embassynetwork.com/locations/example, including paths like /stay. domain mapping would mean that the custom url remains in the URL bar. we would also support subdomains like mycommunity.embassynetwork.com for communities without their own domains.
- nginx config file for mapped domains
- wildcard subdomains
Target: end of November 2015
- remove network nav bar
- create new landing page, and new static content pages explaining the site model
- redesign community landing pages to optionally (?) include a slideout side panel on-hover which links to other locations.
- considering modifying site language around "communities" instead of "locations," "members" instead of "residents." This will involve renaming paths and automated email addresses, so redirects from old to new will be needed.
- there is also a question about whether we want to keep things at embassynetwork.com or move it to another domain, in recognition of separating out the embassy network from the software platform.
Target: early 2016
Support for defining and sharing arbitrary resources.
- Conceptually, imagine that instead of defining only "rooms" you could define anything to share - Eg. tools, food, conference rooms, saunas...
- And these resources could be available at specific times and/or days, paid or free.
- Adding in new visibility layers for resources (including rooms), such that a resource can be shared either publicly, within a community, and/or to explicitly invited external members.
Target: ?
This would help communities use this more like a calendar. weekly dinners, house meetings, standing happy hours and classes all make use of recurring events.
- separate event model into event series and event instance
- payments per event or per series? workflow to manage this.
- potentially a landing page for a series? (can also function as a class homepage, but not always needed)
Target: ?
- ability to calculate and manage payouts to locations from within the software
- ability to automate payouts every N days including automated invoicing and tracking