Tribes and Projects: questions, suggestions, and bugs.
rich hardy
First of all, congratulations on the new release!
Sorry for the long mail, but I'm at the stage where I'm about to make
a stab at a few customizations to the code, and since the project is
still at an early release I'm going to be a bit cautious before I
change too much.
My main interests at the moment are in the design decisions made in
the separation of tribes and projects, and what the future holds for
these two modules in the Pinax Project, especially with the soon to be
integrated django-schedule (which is great btw!)
The code and functionality of the tribes and projects modules is very
similar, and apart from a few tweaks, the main code difference I found
is the addition of the ProjectMember class in projects.
What is the main reason for separating these two similar projects,
when most new features are going to have to be added to both sets of
code? (think: django-schedule) Is there a roadmap that necesitates
this separation?
For some background, I have listed below the features that
differentiate the two.
Projects:
* projects can be private (but there doesn't seem to be a way to
enforce this yet)
* users have to be invited to join projects
* a project can be deleted at any time by the creater
* projects have tasks
Tribes:
* tribes are open for anyone to join
* a tribe can can only be deleted by the creater when he is the only
remaining member
* every user in the system is notified when a new tribe is created.
* tribes have tweets (but nowhere to 'tweet'?)
* tribes don't have tasks
These are some features that could be useful:
1) tasks for tribes (why should only projects have tasks?)
2) user can ask for an invitation to join a public project
3) tribe members can invite others to join a tribe
4) members can be refused entry/removed from tribe
5) selected wiki pages/tasks to be public/private to non-members of
project/tribe
6) tweets within projects/tribes
7) tribe/project creater can leave the tribe/project without deleting
the tribe/project
8) site owner can create a tribe with no members (i.e to create
pre-named, empty, tribes on rollout)
9) tribes within tribes (i.e. a tribe for linux users, with sub-tribes
of ubuntu, fedora etc)
10) projects within tribes (i.e. a subset of a tribe users who create a project)
Bugs:
1) An invitee to a project is added directly - he cannot reject the
invitation, nor delete himself from the project
2) The profile pages only shows 'Your Tribes' (there is no 'Your Projects')
2) In the tribe page, when you click on comments it takes you to the
photos page.
3) If I create a tribe, the first screen that comes up has a delete
button, but it also says 'You are the creator of this tribe so can't
leave (yet).' (it's misleading)
4) Missing from projects/admin.py:
from projects.models import ProjectMember
class ProjectMemberAdmin(admin.ModelAdmin):
list_display = ('user', 'away', 'away_message', 'away_since')
admin.site.register(ProjectMember, ProjectMemberAdmin)
OK, I hope what I wrote made sense!
Cheers,
Rich
James Tauber
On Oct 28, 2008, at 8:23 PM, rich hardy wrote:
[...]
> What is the main reason for separating these two similar projects,
> when most new features are going to have to be added to both sets of
> code? (think: django-schedule) Is there a roadmap that necesitates
> this separation?
I've been thinking for a while that projects and tribes could be the
same app with just configuration differences.
So there would be some sort of "Group" and the site developer could
configure whether their instantiation of Group would be private or
not, invite only or note, whether it would have a wiki, tasks, photos,
discussions, etc. (and then soon calendars, bookmarks, documents, etc)
It would be possible for a single site to have multiple types of
Groups with different settings so the current functionality of cloud27
or pinax's complete_project could be emulated.
[...]
> * tribes have tweets (but nowhere to 'tweet'?)
If you say #pinax in a tweet it gets linked to the tribe with slug
"pinax"
> 1) tasks for tribes (why should only projects have tasks?)
see above
> 2) user can ask for an invitation to join a public project
+1
> 3) tribe members can invite others to join a tribe
this is in plan as a generic capability to invite any user to some
object
> 4) members can be refused entry/removed from tribe
+1 but needs design discussion -- we'll need to (optionally) have
multiple levels of tribe membership
> 5) selected wiki pages/tasks to be public/private to non-members of
> project/tribe
feature request for wikiapp
> 6) tweets within projects/tribes
+1
> 7) tribe/project creater can leave the tribe/project without deleting
> the tribe/project
that's planned
> 8) site owner can create a tribe with no members (i.e to create
> pre-named, empty, tribes on rollout)
+1 hadn't thought of that, nice idea
> 9) tribes within tribes (i.e. a tribe for linux users, with sub-tribes
> of ubuntu, fedora etc)
I've thought about both that and also complementary tribes: e.g.
Python and Ruby are both language tribes. They are not subsets of a
"language" tribe but rather instances of type "language tribe"
> 10) projects within tribes (i.e. a subset of a tribe users who
> create a project)
Interesting, have to give this some thought. It's doable by convention
now but no formal link between the project and tribe.
In light of my initial comments of course, we're really just talking
about subgroups with different settings.
> Bugs:
Could you file these 4 as issues on code.google.com django-hotclub
project for now?
> 1) An invitee to a project is added directly - he cannot reject the
> invitation, nor delete himself from the project
> 2) The profile pages only shows 'Your Tribes' (there is no 'Your
> Projects')
> 2) In the tribe page, when you click on comments it takes you to the
> photos page.
> 3) If I create a tribe, the first screen that comes up has a delete
> button, but it also says 'You are the creator of this tribe so can't
> leave (yet).' (it's misleading)
> 4) Missing from projects/admin.py:
> from projects.models import ProjectMember
>
> class ProjectMemberAdmin(admin.ModelAdmin):
> list_display = ('user', 'away', 'away_message', 'away_since')
>
> admin.site.register(ProjectMember, ProjectMemberAdmin)
>
> OK, I hope what I wrote made sense!
Yes! Great stuff!
James
Eduardo O. Padoan
> On Oct 28, 2008, at 8:23 PM, rich hardy wrote:
>> 5) selected wiki pages/tasks to be public/private to non-members of
>> project/tribe
>
> feature request for wikiapp
I promess to resume active wikiapp hacking Real Soon Now (tm)
--
Eduardo de Oliveira Padoan
http://djangopeople.net/edcrypt/
http://stopforwarding.us/etiq.html
James Tauber
>
> On Wed, Oct 29, 2008 at 12:12 AM, James Tauber <jta...@jtauber.com>
> wrote:
>> On Oct 28, 2008, at 8:23 PM, rich hardy wrote:
>>> 5) selected wiki pages/tasks to be public/private to non-members of
>>> project/tribe
>>
>> feature request for wikiapp
> http://code.google.com/p/django-wikiapp/issues/list :)
>
> I promess to resume active wikiapp hacking Real Soon Now (tm)
Good. Pinax needs to have a truly great wiki system :-)
bobhaugen
that could unite Tribes and Projects (and also allow you to name them
anything you like - the project I'm working on calls them Circles and
Committees).
The main class is called Org. Orgs have OrgTypes, which can
differentiate their behavior. An Org can also have a parent and
children (e.g. subcommittees).
Any Org can have Tasks. Or wikis, or any of the other components of
the Tribe or Project.
For my project, a Task can also have a parent and children (subtasks).
This stuff is in early prototype stage now. Let me know if it is
interesting, and what you think I should do with it in relation to
Pinax.
Rich Hardy's analysis above will be very useful when I get to the
stage of considering whether this is a good Pinax app (or not). At
the moment, I'm just trying to meet my project requirements.
Fernando Correia
approach of Orgs is very interesting. I think about a "Company" org
type that can have "Departments" and that a separate object (e.g.
People) could be linked to these orgs.
2008/10/29 bobhaugen <bob.h...@gmail.com>:
bobhaugen
wrote:
> approach of Orgs is very interesting. I think about a "Company" org
> type that can have "Departments" and that a separate object (e.g.
> People) could be linked to these orgs.
rich hardy
I like what bob is working on, and it would be great to (at least)
integrate the subcommittee code into the existing tribe/project
framework asap!
Now, unfortunately I don't have enough time to to a proper study on
the next points I'm going to make because I'm going on a 4 day trip in
a few hours, but, anyway:
It might be a good idea to create a generic library from the
'subject/predicate/object' code in django-schedule's
EventRelation/EventRelationManager and use it so that users/groups are
able to access/share content such as wiki pages that exist elsewhere
within the Pinax site (created by other groups or users) or from
anywhere else on the net. (This would also free the wiki pages from
being tied to a group.)
Using a model such as that in BookmarkInstances would drastically
reduce the number of relations held by an object, while providing easy
tracking information on who's relating what to what. In the case of
wiki pages, private revisions could be made by a user/project (that
could be later merged back into the original), and in the general case
of a relation to an item of content, the original item referenced can
be easily replaced if a better version is found (i.e. a better photo)
while retaining the relations. If the calendar model was also used,
then subcommittes/groups could keep a reference to the main group's
items while adding more of their own.
A form to allow for standard site wide, and group specific vocabulary
for the relation 'distinctions' (predicates) of object types - such as
'maintainer', 'verifier', 'creater' etc would be also useful.
OK, once again, I hope I made sense! I look forward to catching up
when I get back!
Cheers,
Rich.