Occupy projects team needs

[Aaron Williamson]

I talked to Devin on Sunday about the Occupy projects team's data-collection
needs and what it would take to get them using Eden instead of a Google Form for
storing & publishing information about projects and project activities happening
at Occupy sites. I wrote up a Blueprint here:
http://eden.sahanafoundation.org/wiki/BluePrint/OccupyProjects -- but the basic
idea is to add a few more fields to the projects model(s), enable project leads
to request services from other teams (like tech or volunteers), and add a couple
of new views (one public, one internal).

I'd appreciate feedback (including on how to improve the blueprint).

Aaron

[Michael Howden]

Hey Aaron,

Luckily for you most of those fields are already available - it's just a case of enabling the right deployment settings - and tweaking some forms:

Have a look at the deployment settings:
https://github.com/flavour/eden/blob/master/modules/s3cfg.py#L1222
They could be documented a lot better - feel free to :)

Have a look at how Fran inserted the activity type into the project_location form here:
https://github.com/flavour/eden/blob/master/private/templates/IFRC/config.py#L348
using this link table:
https://github.com/flavour/eden/blob/master/modules/eden/project.py#L1433
You could do the same for the project_activity and project_project

For media links I'd rename the "Attachments" tab for your site

For partners use project_organisation table
settings.project. multiple_organisations = True

New view - I'll let you have a play around with those :) non-editable - try adding /read to the end of the url (instead of update)

Good luck!

Cheers

Michael

--
Michael Howden
Director, Sahana Software Foundation
Managing Director, AidIQ
mic...@sahanafoundation.org
skype: michael.howden
+64 (21) 126-1360
+1 (213) 261-4250
twitter:@michaelhowden

[Pat Tressel]

Hi, Aaron!

The blueprint looks great!

There is a mechanism for making requests, and for donors to commit resources (material or people).  This can get as detailed as you want:  For material, one can use the inventory system to specify what's wanted.  For people, one can specify particular skills one is looking for.

I wonder if it would be useful to have threaded comments for projects.  If there's already a forum for chat about specific projects, maybe it would be better just to link to that.

Did you want to let people volunteer for or inquire about projects through the site? or would volunteers mainly be coming from partner organizations?

-- Pat

[Louiqa Raschid]

Aaron - If the data that Occupy currently needs for "Projects" can essentially be captured 

in a single table (as seems to be the case now) then it is hard to convince people to move to 

a database solution. A Google Form will work quite well. But if they want to link to other 

concepts, e.g., volunteers signing up, or an organization adopts a project, then there is a 

clear benefit from using Eden and a database solution. Louiqa

[Aaron Williamson]

Hey Pat, forgive the slow response, I've been in Brussels for FOSDEM.

On 01/31/2013 10:54 AM, Pat Tressel wrote:
> The blueprint looks great!

Thanks!

> There is a mechanism for making requests, and for donors to commit resources
> (material or people). This can get as detailed as you want: For material, one
> can use the inventory system to specify what's wanted. For people, one can
> specify particular skills one is looking for.

Yeah, we batted around the possibility of using requests for this, rather than
tasks. One design goal is to keep the number of steps necessary to enter a new
project as small as possible and not to spread the required information all over
the site. That said, requests do seem like a natural fit for this and I should
probably look more closely at them before I commit to using tasks for this.

> I wonder if it would be useful to have threaded comments for projects. If
> there's already a forum for chat about specific projects, maybe it would be
> better just to link to that.

Can you explain this further? You mean to answer inquiries from potential
volunteers?

> Did you want to let people volunteer for or inquire about projects through the
> site? or would volunteers mainly be coming from partner organizations?

I think neither -- we're just publishing (like on the main Sandy Relief site)
the projects in need of volunteers, and people can use the contact information
there to email or call the project lead.

(Devin, please correct me if any of this is wrong or misguided.)

Aaron

[Devin Balkind]

Hi.  This looks like an awesomely fun list!

I help facilitate Occupy Sandy's use of Eden.

Responding to this thread inline...

On Tue, Feb 5, 2013 at 10:47 PM, Aaron Williamson <aa...@copiesofcopies.org> wrote:

Hey Pat, forgive the slow response, I've been in Brussels for FOSDEM.

On 01/31/2013 10:54 AM, Pat Tressel wrote:
> The blueprint looks great!

Thanks!

Agreed!

 

> There is a mechanism for making requests, and for donors to commit resources
> (material or people).  This can get as detailed as you want:  For material, one
> can use the inventory system to specify what's wanted.  For people, one can
> specify particular skills one is looking for.

Yeah, we batted around the possibility of using requests for this, rather than
tasks. One design goal is to keep the number of steps necessary to enter a new
project as small as possible and not to spread the required information all over
the site. That said, requests do seem like a natural fit for this and I should
probably look more closely at them before I commit to using tasks for this.

It's possible that requests would work for this, but I think we'd need a third type of request for "services".

Each service consist of a title , description, contact.  For example: Tech Support - We build and maintain websites, mailing lists and other technical services relief organizations need. - te...@nycga.net.

The request form could be the same as "Request People" except instead of skills, they would select from a menu of service, such as Tech Support, Grant Writing, Legal Aid, etc.  When a project or site makes a request for service, that request should go into a "Services" queue and be automatically emailed to the registered contact for that service.

There are two ways to manage information about services.

One way, and I'd imagine the easiest way, would be to give people with the "Project Support Admin" user role the ability to manage services information.  

The second, and I'd imagine harder way, would be to attach services to an entity (object?) in Sahana.  Then, people who are associated with that entity could manage information about the service they're providing by filling out basic details, manage the provision of that service via their entity's service request queue, and manage who can commit to those request by defining who is in the entity.  

I don't know which entity would be most appropriate.  Since organizations have the ability to list their projects, maybe we could define services as a specific type of project?  Since Teams/Groups seems pretty simple at this point, maybe it would be easiest to add a services section to that entity?  I don't know - but I do think simply giving folks the ability to request a service with an email automatically going to the registered service provider would be a great solution to start with.

The other really useful thing would be to give projects (and facilities if possible) the ability to log into the system and manage requests for both people, materials and services from their own profile pages.  Project or facility information would be automatically attached to their requests and they could view a queue of their outstanding requests.  This would require a bit of UX work, but not much.  We currently have "project owner" user roles that give people access to edit their own project.  When they log in, they see the normal dashboard but don't have the ability to click on any of the "request" buttons.  If they had that ability but could only make requests for their own project/site, that would be a major improvement.  If, on their dashboard, they could also see a queue of outstanding requests, that'd be another really useful feature.

 

> I wonder if it would be useful to have threaded comments for projects.  If
> there's already a forum for chat about specific projects, maybe it would be
> better just to link to that.

Can you explain this further? You mean to answer inquiries from potential
volunteers?

Most projects have no online presence. 

Threaded comments on projects would be quite useful for Project Support Admins.  They call projects and sites in the network to get info about how things are going and they want the ability to add chronological notes to projects so everyone on the team can stay updated on what's happening with that project.  Ideally they're be a set of notes that only Project Support Admins and project owners could see - and super ideally people could select wether they want notes to be public or private so that the same function could be used to create a news feed for the project.

 

> Did you want to let people volunteer for or inquire about projects through the
> site? or would volunteers mainly be coming from partner organizations?

I think neither -- we're just publishing (like on the main Sandy Relief site)
the projects in need of volunteers, and people can use the contact information
there to email or call the project lead.

It would be ideal if volunteers could inquire about opportunities via the site.

Ideally, we could have a public "people request" queue.  People could click on a request, go to a "register screen" where they'd receive an account with a volunteer user role, and then view all requests, commit to fulfilling a request, receive an email the day before (or immediately) asking them to confirm they're going, if they click yes then the system would change their their status to sent.  I think that would be a really awesome volunteer solution!

 

(Devin, please correct me if any of this is wrong or misguided.)

Aaron, I think you've got the right idea for sure!  Are you coming out to the ITP Sandy hack event this weekend?  I'll be there on Saturday and lots of Occupy Sandy tech people will be there both days.

Eden community, let me know if writing out specs like this is an inappropriate use of the listserv.  If you're interested in other ways we'd like to use the eden system for Occupy Sandy, I've got a requirements google doc (that I need to update with all the info in this email and add to the eden wiki) here.

If you're into Occupy + Free/Libre/Open-source:

* here's a blog post about Occupy Sandy databases

* here's a longer story about Occupy Wall Street's commitment to free/libre/open-source

* here's a chapter I wrote in a poli sci book about FLO and Occupy.

Thanks so much for Eden and looking forward to more collaboration!

 

Aaron

--
Devin Balkind
Founder & Director

Sarapis
134 Spring St, Suite 302
New York, NY, 1001
m.917.748.1048
de...@sarap.is
www.sarap.is

[Fran Boon]

You have a good understanding of how Sahana works :)
As you say, a simple Admin role can manage the 'Services' lookup list
or else (harder but more ideal) this is delegated to members of an
Entity

> I don't know which entity would be most appropriate. Since organizations
> have the ability to list their projects, maybe we could define services as a
> specific type of project?

I'm not sure I like that

> Since Teams/Groups seems pretty simple at this
> point, maybe it would be easiest to add a services section to that entity?

We can use pe_id & thus make Services use the 'Person Entity' which
can work for a single Person, a Team or an Organisation.
i.e. we are less prescriptive about which Entity type manages a queue.

> I don't know - but I do think simply giving folks the ability to request a
> service with an email automatically going to the registered service provider
> would be a great solution to start with.

Notifications can be done through the 'Saved Search & Subscription'
functionality.
This allows users to select the results of a Search (e.g. all
unassigned requests in the X services queue) & be notified of new
matches in that search result.

> The other really useful thing would be to give projects (and facilities if
> possible) the ability to log into the system

Users log-in, not Projects/Facilities.

> and manage requests for both
> people, materials and services from their own profile pages.

Facilities already have a requests tab, which shows the requests made
by that facility.

> Project or
> facility information would be automatically attached to their requests and
> they could view a queue of their outstanding requests. This would require a
> bit of UX work, but not much. We currently have "project owner" user roles
> that give people access to edit their own project. When they log in, they
> see the normal dashboard but don't have the ability to click on any of the
> "request" buttons. If they had that ability but could only make requests
> for their own project/site, that would be a major improvement. If, on their
> dashboard, they could also see a queue of outstanding requests, that'd be
> another really useful feature.

Definitely possible to limit a user's ability to log requests to just
their own site.

Linking Requests to Projects can be done by creating a link table
holding both project_id & req_id
This then allows Requests to be made a component of Projects, so they
can have their own tab, which is the filtered view you want and also
allow us to set permissions so they can only make requests for their
Project.
There are various different options for how this link table acts:
http://eden.sahanafoundation.org/wiki/S3XRC/ModelExtensions/ComponentResources#LinkActuationOptions

One big thing we may need to change is then allowing Requests to be
made without specifying a Facility - currently this is a mandatory
field & changing this may have implications (would be a
deployment_setting anyway to mitigate impact)

>> > I wonder if it would be useful to have threaded comments for projects.
>> > If
>> > there's already a forum for chat about specific projects, maybe it would
>> > be better just to link to that.
>> Can you explain this further? You mean to answer inquiries from potential
>> volunteers?
> Most projects have no online presence.
> Threaded comments on projects would be quite useful for Project Support
> Admins. They call projects and sites in the network to get info about how
> things are going and they want the ability to add chronological notes to
> projects so everyone on the team can stay updated on what's happening with
> that project. Ideally they're be a set of notes that only Project Support
> Admins and project owners could see

This should be straightforward.

> - and super ideally people could select
> wether they want notes to be public or private so that the same function
> could be used to create a news feed for the project.

This would require a bit of new work....volunteers welcomed ;)

>> > Did you want to let people volunteer for or inquire about projects
>> > through the
>> > site? or would volunteers mainly be coming from partner organizations?
>> I think neither -- we're just publishing (like on the main Sandy Relief
>> site)
>> the projects in need of volunteers, and people can use the contact
>> information
>> there to email or call the project lead.
> It would be ideal if volunteers could inquire about opportunities via the
> site.
> Ideally, we could have a public "people request" queue. People could click
> on a request, go to a "register screen" where they'd receive an account with
> a volunteer user role, and then view all requests, commit to fulfilling a
> request, receive an email the day before (or immediately) asking them to
> confirm they're going, if they click yes then the system would change their
> their status to sent. I think that would be a really awesome volunteer
> solution!

This is now talking about normal Skill Requests, not Services, right?
This is definitely how things should work - the Give2LA system worked
like that but due to delays in getting the code made public
(contractual issues) this functionality isn't completely ported to
trunk yet.
It won't be too hard to do this though.
(As always, what takes time is polishing this to specific usecases)

> Eden community, let me know if writing out specs like this is an
> inappropriate use of the listserv.

Discussing BluePrints is a very appropriate use of the listserv :)
However it's best if the results of the discussions are written back
up in the Blueprint as they'll get lost here...

> Thanks so much for Eden and looking forward to more collaboration!

:)

[Devin]

We can use pe_id & thus make Services use the 'Person Entity' which
can work for a single Person, a Team or an Organisation.
i.e. we are less prescriptive about which Entity type manages a queue.

Does this mean that a Service becomes a "Person Entitiy" or that a service becomes a characteristic/trait of a Person Entity, and thus would be listed under a Person, Team or Organization depending on how that service is set up?

 

> I don't know - but I do think simply giving folks the ability to request a
> service with an email automatically going to the registered service provider
> would be a great solution to start with.

Notifications can be done through the 'Saved Search & Subscription'
functionality.
This allows users to select the results of a Search (e.g. all
unassigned requests in the X services queue) & be notified of new
matches in that search result.

Yay.  Would it be possible for person entities to see a queue of their pending requests?

 

> The other really useful thing would be to give projects (and facilities if
> possible) the ability to log into the system

Users log-in, not Projects/Facilities.

Yes I know, I misspoke.  

 

> and manage requests for both
> people, materials and services from their own profile pages.

Facilities already have a requests tab, which shows the requests made
by that facility.

I don't see a "requests" tab on facilities, just a "needs" tab, but that doesn't tie into the request queue.

 

> Project or
> facility information would be automatically attached to their requests and
> they could view a queue of their outstanding requests.  This would require a
> bit of UX work, but not much.  We currently have "project owner" user roles
> that give people access to edit their own project.  When they log in, they
> see the normal dashboard but don't have the ability to click on any of the
> "request" buttons.  If they had that ability but could only make requests
> for their own project/site, that would be a major improvement.  If, on their
> dashboard, they could also see a queue of outstanding requests, that'd be
> another really useful feature.

Definitely possible to limit a user's ability to log requests to just
their own site.

This would be extremely useful and dramatically simply the UX for project participants.

 

Linking Requests to Projects can be done by creating a link table
holding both project_id & req_id
This then allows Requests to be made a component of Projects, so they
can have their own tab, which is the filtered view you want and also
allow us to set permissions so they can only make requests for their
Project.
There are various different options for how this link table acts:
http://eden.sahanafoundation.org/wiki/S3XRC/ModelExtensions/ComponentResources#LinkActuationOptions   

 

One big thing we may need to change is then allowing Requests to be
made without specifying a Facility - currently this is a mandatory
field & changing this may have implications (would be a
deployment_setting anyway to mitigate impact)

How would this work?  Do you know if Aaron or Tony could handle something like this?

>> > Did you want to let people volunteer for or inquire about projects
>> > through the
>> > site? or would volunteers mainly be coming from partner organizations?
>> I think neither -- we're just publishing (like on the main Sandy Relief
>> site)
>> the projects in need of volunteers, and people can use the contact
>> information
>> there to email or call the project lead.
> It would be ideal if volunteers could inquire about opportunities via the
> site.
> Ideally, we could have a public "people request" queue.  People could click
> on a request, go to a "register screen" where they'd receive an account with
> a volunteer user role, and then view all requests, commit to fulfilling a
> request, receive an email the day before (or immediately) asking them to
> confirm they're going, if they click yes then the system would change their
> their status to sent.  I think that would be a really awesome volunteer
> solution!

This is now talking about normal Skill Requests, not Services, right?

Yes, these would be skill requests.

 

This is definitely how things should work - the Give2LA system worked
like that but due to delays in getting the code made public
(contractual issues) this functionality isn't completely ported to
trunk yet.
It won't be too hard to do this though.
(As always, what takes time is polishing this to specific usecases)

Once we've got the projects and services stuff done, I'll tackle the volunteer tracking stuff.  There is a lot of demand for this and I can see we'd need to do some work to flush out the UX.  

 

> Eden community, let me know if writing out specs like this is an
> inappropriate use of the listserv.

Discussing BluePrints is a very appropriate use of the listserv :)
However it's best if the results of the discussions are written back
up in the Blueprint as they'll get lost here...

I'm doing my best to add to Aaron's blueprints doc and we'll hopefully go over this and integrate the doc this weekend.

[Fran Boon]

On 8 February 2013 21:28, Devin <de...@sarap.is> wrote:
>> We can use pe_id & thus make Services use the 'Person Entity' which
>> can work for a single Person, a Team or an Organisation.
>> i.e. we are less prescriptive about which Entity type manages a queue.
> Does this mean that a Service becomes a "Person Entitiy" or that a service
> becomes a characteristic/trait of a Person Entity, and thus would be listed
> under a Person, Team or Organization depending on how that service is set
> up?

We have both options available.
I don't think of a Service as an 'instance type' of a Person Entity so
was rather suggesting making it a 'Component' of any/all Person
Entities.
However do we want different Entities to offer a range of Services?
I don't think we actually need either of these in this case.

The requirement came from restricting write access - this can be done
either through ownership (auth_user, auth_group) or through a realm
(any Person Entity: Person/Team/Facility/Organisation):
https://github.com/flavour/eden/blob/master/modules/s3/s3fields.py#L868

If we wish others to be able to see the status of the request then a
realm-restriction would also require delegation of the reader role to
AUTHENTICATED or even ANONYMOUS..

>> > I don't know - but I do think simply giving folks the ability to request
>> > a
>> > service with an email automatically going to the registered service
>> > provider
>> > would be a great solution to start with.
>> Notifications can be done through the 'Saved Search & Subscription'
>> functionality.
>> This allows users to select the results of a Search (e.g. all
>> unassigned requests in the X services queue) & be notified of new
>> matches in that search result.
> Yay. Would it be possible for person entities to see a queue of their
> pending requests?

Since we assume that all users can see all requests(?) then this
requires making Requests a Component of the Entity, which can be done
through a link table if there is no direct Foreign key within the
component table.
This allows the easy filtering of a list.

>> > and manage requests for both
>> > people, materials and services from their own profile pages.
>> Facilities already have a requests tab, which shows the requests made
>> by that facility.
> I don't see a "requests" tab on facilities, just a "needs" tab, but that
> doesn't tie into the request queue.

No, 'needs' is the simple warehousing system which was to be tied into
high level broadcasting via social media - rather than the detailed
transactional-level of requests.

Showing Requests tabs is a deployment_setting which defaults to
Off...I'll enable in the SR template & update site.

>> One big thing we may need to change is then allowing Requests to be
>> made without specifying a Facility - currently this is a mandatory
>> field & changing this may have implications (would be a
>> deployment_setting anyway to mitigate impact)
> How would this work? Do you know if Aaron or Tony could handle something
> like this?

Given time, of course :)

F

[Fran Boon]

On 8 February 2013 22:42, Fran Boon <franc...@gmail.com> wrote:
> Showing Requests tabs is a deployment_setting which defaults to
> Off...I'll enable in the SR template & update site.

Actually, defaults to True, but was off deliberately in the Sandy
template...I guess to try & keep the interface a little simpler.
I amended the template anyway & updated the TEST server to current
trunk, which includes this change (as well as a whole lot of others,
of course).

F

[Aaron Williamson]

Hey Michael, some follow-up questions:

On 01/31/2013 07:59 AM, Michael Howden wrote:
> Have a look at how Fran inserted the activity type into the project_location
> form here:
> https://github.com/flavour/eden/blob/master/private/templates/IFRC/config.py#L348
> using this link table:
> https://github.com/flavour/eden/blob/master/modules/eden/project.py#L1433
> You could do the same for the project_activity and project_project

So I would need to create an activity type-to-project link table?

> For media links I'd rename the "Attachments" tab for your site

What's the best way to do this? Is it possible to do template-specific localisation?

Thanks,
Aaron

[Michael Howden]

On 11/02/13 4:04 AM, Aaron Williamson wrote:

Hey Michael, some follow-up questions:

On 01/31/2013 07:59 AM, Michael Howden wrote:

Have a look at how Fran inserted the activity type into the project_location
form here:
https://github.com/flavour/eden/blob/master/private/templates/IFRC/config.py#L348
using this link table:
https://github.com/flavour/eden/blob/master/modules/eden/project.py#L1433
You could do the same for the project_activity and project_project

So I would need to create an activity type-to-project link table?

Yes, I believe so.

For media links I'd rename the "Attachments" tab for your site

What's the best way to do this? Is it possible to do template-specific localisation?

Have a look at this:
https://github.com/flavour/eden/blob/master/private/templates/DRRPP/config.py#L152
def customize_project_project(**attr):

https://github.com/flavour/eden/blob/master/private/templates/DRRPP/config.py#L329
settings.ui.customize_project_project = customize_project_project

This allows you to define a function which is called in the controller (after all the existing code) for any resource:
settings.ui.customize_<resourcename> = fucntion


Cheers

Michael

[Aaron Williamson]

On 02/07/2013 07:26 AM, Fran Boon wrote:
>
> Linking Requests to Projects can be done by creating a link table
> holding both project_id & req_id
> This then allows Requests to be made a component of Projects, so they
> can have their own tab, which is the filtered view you want and also
> allow us to set permissions so they can only make requests for their
> Project.
> There are various different options for how this link table acts:
> http://eden.sahanafoundation.org/wiki/S3XRC/ModelExtensions/ComponentResources#LinkActuationOptions

Would it be better to define this link table in the project model or the skill
request model?

>> Threaded comments on projects would be quite useful for Project Support
>> Admins. They call projects and sites in the network to get info about how
>> things are going and they want the ability to add chronological notes to
>> projects so everyone on the team can stay updated on what's happening with
>> that project. Ideally they're be a set of notes that only Project Support
>> Admins and project owners could see
>
> This should be straightforward.

Humor me ;) I see that threaded comments are implemented in the CMS module, but
there's a fair amount of front-end code there to support it. It seems un-DRY to
port all that over to projects -- does it need to be pulled out to neutral
territory for use by both modules? Or am I barking up the wrong tree here?

Aaron

[Fran Boon]

On 16 February 2013 17:03, Aaron Williamson <aa...@copiesofcopies.org> wrote:
> On 02/07/2013 07:26 AM, Fran Boon wrote:
>>
>> Linking Requests to Projects can be done by creating a link table
>> holding both project_id & req_id
>> This then allows Requests to be made a component of Projects, so they
>> can have their own tab, which is the filtered view you want and also
>> allow us to set permissions so they can only make requests for their
>> Project.
>> There are various different options for how this link table acts:
>> http://eden.sahanafoundation.org/wiki/S3XRC/ModelExtensions/ComponentResources#LinkActuationOptions
> Would it be better to define this link table in the project model or the skill
> request model?

It should be in it's own class so that the other module is optional &
it doesn't interfere with anything else.
Whether that class lives in Projects or Requests makes no real difference.

>>> Threaded comments on projects would be quite useful for Project Support
>>> Admins. They call projects and sites in the network to get info about how
>>> things are going and they want the ability to add chronological notes to
>>> projects so everyone on the team can stay updated on what's happening with
>>> that project. Ideally they're be a set of notes that only Project Support
>>> Admins and project owners could see
>> This should be straightforward.
> Humor me ;) I see that threaded comments are implemented in the CMS module, but
> there's a fair amount of front-end code there to support it. It seems un-DRY to
> port all that over to projects -- does it need to be pulled out to neutral
> territory for use by both modules? Or am I barking up the wrong tree here?

Of course yes, it would be useful to DRY it further.
I think the 'key' would be to link Comments to a new Super Entity so
that they can be made components of many different resources without a
separate FK to each.
- similar to the doc_entity

In fact I'd be tempted to simply use the existing doc_entity as we
don't really want to introduce more Super Entities if we can avoid it.

F