5 réponses à ce sujet

[Sunjammer]

The more I use site the less the "a Project inherits it's members from the Group (or no Group)" thing is  working for me.



For example ...

• In order to work on the project an individual needs to join the parent group: this prevents me from simply inviting an individual to work on a project.  If I own the project but don't have the ability to invite people to the group I'm going to have to request the groups owner/officiers to do that for me.

• There can only be 0 or 1 parent group associated with a project: if I want to draw people from 2+ groups or 1 group and a bunch of non-members I need to set up a new group, invite everyone individually and this also has the prerequisite of being friends with them.

• If someone leaves a Project but not a Group what then?  They still have access to the all the project's resources and discussions, etc.  If there was bad blood (and lets face it half the Community will fall out with each other over the course of the next few years) project leads/members may feel exposed.

• When I want to send a message to a Project member I have to navigate to the appropriate Group (which fortunately appears in the little project summary box) and go to its members tab to find them.  It's only a couple of extra clicks but it seems unnecessary.  Even if the Group-Project relationship is unchange this could be resolved by duplicating the Member's tab from the Group in the Project.

Also a wee Group/Project feature request:

• Ability to message everyone on a Project and/or in a Group (currently the same thing).

Modifié par Sunjammer, 11 août 2009 - 11:08 .

[Sunjammer]

Also bulleted lists don't render the same in the editor and in the forum!

[Proleric]

So, as it stands, the workaround would be to create a dedicated group for each project?



Which could be inconvenient.

[Jesse van Herk]

That was what we were assuming people would do, yes.



If we did split the link between groups and projects, we would lose the ability to see the list of projects that a group is involved with. Is that a reasonable loss?

[Jassper]

This is my 2 cents



A project without a group would simply be my "personal" projects. I could then set permissions on them for anyone, only registered use, etc, or by "Invitation only".



A project associated with a group, then only group members could see by default, and/or by Invitation only, or All registered users. Anyone invited to the project that is not in that group can only see that project within that group. The creator of the project should have full control, owner of its associated group need not be present. OR, allow us to link to a "personal" project with a group. This way if I want my project that is already in a group to become public, I don't need to create a second project without a group or disassociate that project from the group or visa-versa



I hope that made sense.

[Proleric]

Jesse van Herk wrote...

That was what we were assuming people would do, yes.



If we did split the link between groups and projects, we would lose the ability to see the list of projects that a group is involved with. Is that a reasonable loss?

[END QUOTE]



Perhaps I'm missing something, but I don't seem to have that ability at present!



However, I guess players and builders are going to need a much more powerful search tool once the number of community contributions is significant (another topic in its own right).



Assuming that group is the "brand name" by which the team is known to the community, it's incredibly important for marketing purposes, and a must-have for searching.



In which case, on reflection, we need the link, and one-to-many group-to-project.



I guess we need to clarify the requirement for group member and project member information.



For access permission purposes, smaller groups could probably live with a list of current members at group level IMO.



I can understand that larger groups with concurrent projects might have a more granular requirement.



Then there is the entirely separate question of how group/project members are displayed for the purposes of giving high-profile public credit.  



While access control is driven by the joiner/leaver events and need-to-know, credit is more subjective.



Ideally, I'd like to be able to specify whether someone gets a core team credit, an "assisted by", or no credit -  with an indication of whether the person has left the team - at both group and project level.



What do people think?