There are some organizations who wish to share an account among multiple people to manage their content on drupal.org. Historically that has not been allowed (to prevent sock puppet accounts, among other reasons).

There are, however, some reasons why sharing accounts is a helpful thing.

So, here is a proposed set of guidelines for how an account can be shared:

  • Having an Organization node owned by a shared organization account makes it easy for that node to be edited even if the original author leaves the organization
  • Having a project node owned by an organization, similarly, let's that organization manage the project even if a developer hired to work on it leaves the organization
  • Contributing translations to localize.drupal.org can be easier via a shared account when the translations are done on client sites
  • Case studies can be authored by a shared organization account
  • All other forms of interactions (creation of nodes, committing code) should not be done by multiple people using a single account.
  • The organization is 100% responsible for the security and use of the account - if it is used inappropriately (e.g. spam, posting ads in the hosting forum) it will be blocked the same as any individual account will be blocked.

Comments

jenlampton’s picture

I've seen a lot of these accounts lately. When a company or organization wants to "own" the code their employees contribute, they create an account that everyone at the company shares. It's a little weird, frankly, and I'm not sure how they handle SSH keys or git project access.

Maybe we should look at how github solves this problem and emulate their company account policy?

zirvap’s picture

greggles’s picture

I've requested that the folks responsible for this explain what happened in the next 2 weeks. I've added a calendar reminder and will post my knowledge of the situation if they don't. Small spoiler: the WhiteHouse has behaved appropriately.

AdamEvertsson’s picture

I do not know if "the folks responsible for this" applies to me and the company I work for, but since it was I who requested to create an account for the company I work for I take the opportunity to say something about it.

I have been trying to get the company I work for to give back to the community, I since I am a Swede naturally I suggested that we'd help out with the translations of Drupal core and modules. But since we all work logged in as user/1 in our projects (well, ok, not all the time, but during the production phase anyhow) we wanted an account that we could use for these translations. I posted the question at https://drupal.org/node/1817546 and got a positive response a couple of months back.

I wasn't aware of the account policy or that we suddenly ended up on the same level as the White house (which by the way is kind of cool), but I've said my piece and will follow this as it goes along. I do not want my action or my company to break any policies.

Yours truly,
Adam Evertsson

greggles’s picture

Hi Adam,

I was referring specifically to the Whitehouse account.

My personal hope is that this will be a catalyst that helps other companies who wish to contribute some things as a company so that they can do it. Thanks for your patience :)

greggles’s picture

Status: Active » Closed (works as designed)

So, my memory of the brief description I read in February is that the organization behind the whitehouse account signed a special terms of use with the Drupal Association to let the organization have multiple people use a single account. From the perspective of this specific issue, it's "works as designed" or "fixed." If someone wants to expand this issue to cover making that an acceptable policy for all organizations (personally I'd be opposed to that, without some specific caveats) or if someone wants to reverse that, please feel free to update the title to reflect that.

greggles’s picture

Sidenote: as someone who donates time to try to keep drupal.org's content/user accounts flowing smoothly I think it's really annoying that a terms-of-use was created
1. without asking for feedback
2. without presenting it aftward so I can do that moderation in-line with the terms-of-use

killes@www.drop.org’s picture

Status: Closed (works as designed) » Active

As long as there's no public verifyable information regarding this, there's no reason to mark this closed.

And I have to say that I strongly disagree with making special-ToS for some organizations and not for others.

greggles’s picture

Title: Whitehouse account does not follow drupal.org account policy. » Create ToS to allow organizations to share accounts

OK, how about this.

greggles’s picture

Anyone feel like discussing the guidelines in the OP?

Here are the proposed ways an organization can and can't share an account:

  • Having an "organization node" owned by a shared organization account makes it easy for that node to be edited even if the original author leaves the organization
  • Having a project node owned by an organization, similarly, let's that organization manage the project even if a developer hired to work on it leaves the organization
  • Contributing translations to localize.drupal.org can be easier via a shared account when the translations are done on client sites
  • All other forms of interactions (creation of nodes, committing code) should not be done by multiple people using a single account.

Edit to clarify that this is a proposal

WorldFallz’s picture

The only other thing I would add to #10 is that case studies can be owned by the org account.

WorldFallz’s picture

Issue summary: View changes

making more generic

greggles’s picture

Great point, WorldFallz. I agree that has caused problems in the past and is a reasonable thing since the case study is with the company (even if the employees of the company change) . Updated the OP with that.

killes@www.drop.org’s picture

The reason that we agreed to not allow organization accounts nodes was that some org had owned a project and they kept doing things we didn't want them to do (this was several years ago, I still know which account that was but it doesn't matter now).

When we approached them through the contact form, they would never reply or even acknowledge that they got a mail. Only when we took away their project, we got replies from them, basically saying it was "the other guy" etc. yadayada.

The whole thing put considerable stress on the webmaster team and that's why we didn't want this to happen again..

Therefore, our advice was (and IMO it should continue to be) that each person within the organization gets their own account. If they want to transfer nodes, they open a webmaster request and the node gets transferred.

The exception made in Adam's case was made due to technical limitations of the translations process (or at least I thought there were limitations).

killes@www.drop.org’s picture

Or to paraphrase the above: where there is shared responsibility, there is none.

mlhess’s picture

I agree with @killes above. This is a community and communities are made up of people not organizations, people may of course be a part of an organization, but it is the people that make Drupal strong.

webchick’s picture

FWIW, at the Drupal Association Board retreat last month, we had a very similar discussion about how we could better enable organizations to contribute code, and came up with guidelines much the same as those in the issue summary, particularly emphasizing the importance of individuals owning commits/issue communication. Unfortunately, I don't think anyone took the action item to come back to the issue queue with a proposal, since it was only a side-discussion, but +1 from me (and Danese, and Cary, and Vesa, and... ;))

"whitehouse" though is definitely a bit of a special case, but I'll respond over at the other issue about that once Dries and I have had a chance to sync up.

webchick’s picture

Btw, for those opposing this, I don't understand why transparency around who actually maintains projects is a bad thing?

For example, http://drupal.org/project/spark is owned by "Dries" who has never done a single commit, and probably not even a single git clone. :) How is that helpful? "Acquia" would communicate (truthfully) that there's a company behind this project that designs, develops, and maintains it. That seems like useful information for end-users to know when evaluating projects. And when evaluating companies, too, for that matter; what better motivation for staying on top of your issue queue than the risk of ruining your "brand" due to neglect? ;)

jredding’s picture

@greggles offering clarification here.

You are correct that there is a one-off agreement between the Executive Office of the President (of the United States) (EOP) and the Drupal Association. I signed and entered the DA into that agreement after reviewing it with Dries and Angela along with other members of the board. It also underwent a few revisions to ensure that the agreement follows the existing TOS of Drupal.org without modification with only one exception; the agreement states that the Terms of Service for the EOP will be governed by the laws of the United States.

This seemed a very reasonable agreement as the EOP must explicitly operate under U.S law and the terms of service on Drupal.org does not mention a specific country law. Our choice was to either modify Drupal.org to explicitly state the U.S as the governing body of law or sign a one-off agreement.

The EOP must still follow the TOC like all other users on Drupal.org without exception.

jredding’s picture

Following up on http://drupal.org/node/1948254 as relevant to this thread.

Like many organizations the Executive Office of the President (i.e. Whitehouse) wanted the credit for the module to go to the Whitehouse.
They believe it important to show the world that the U.S government via the White house was contributing to an Open Source project (and I strongly support this). Maintenance and work on the module would go to individual developers (ex: http://drupal.org/project/petitions). Unfortunately on Drupal.org it is the username that receives credit for a module, so the simple solution was for them to just use the word "Whitehouse" as the username. Then their modules would read "Module Name posted by Whitehouse" instead of "Posted by one-of-the-team-members".

Fixing the TOS is only one step to solving this problem. The issue of an organization posting a module could be solved another way by having a module byline that read something like.

Spark
Sponsored by Acquia
--Posted by Dries on April 20, 2012 at 7:27pm

instead of
Spark
Posted by Dries on April 20, 2012 at 7:27pm

Although I understand this is not a perfect solution because it may not be a single company that created the module but by the same token it's often not a single developer that creates a module. If we give the power to the module maintainers to turn on/off the sponsorship field we should be able to alleviate this issue until a more robust long-term solution can be found/designed.

fwiw: Ohloh just implemented Organization code statistics in a very similar and simplistic manner.

jredding’s picture

@greggles agree with what you put in #10 and Worldfallz contributions in #11.

Would love to see this get implemented at some point.

DSquaredB’s picture

From my work in the content issue queues I see a lot of companies create an organization node with minimal or incomplete information and then never come back to complete it. That could be because one member of the team creates the node but doesn't have all the information and no one else can edit it. Or, as I have also seen, the organization node is created with what I suspect probably is a "company" d.o account and no one responds because no one remembers to monitor that account. I've even had a couple of them tell me that was why no one responded.

On one hand, I agree that shared responsibility equals no responsibility. On the other hand, I would rather know I was dealing with a company account than to think the Marketplace reviews were just being ignored. If we allow company accounts, it would be really helpful to have some way for reviewers to know who in the company to contact when necessary during the review process.

jredding’s picture

@DSquaredB I offered a solution for that in the Marketplace review guidelines by requiring companies to update their profile at least once a year, after a few automated reminders and no up-to-date timestamp the listing would be unpublished. Companies pay attention once they are delisted and it would be their fault for not paying attention to the emails.

DSquaredB’s picture

@jredding - agree that delisting gets their attention. I've been on the receiving end of that attention a time or two. It's the ones that never get listed in the first place that we spend time on. There are a bunch of Closed-won't fix issues because no one ever responded after the node was created and initially reviewed.

I'm not against company accounts, just wish there would be a way to know who was a primary contact at that company for cases like when they create three organization nodes which results in three review issues and we need to figure out what they were really trying to do. Luckily those don't happen every day and we can always try to track down some individual at the company in those cases, so maybe it's not that big a deal.

jredding’s picture

@dsquaredB. Seems like a process issue. Perhaps stating that org accounts must be responded to within 72 hours or the application will be considered void. Of course this would need to be reciprocated as well by the review team but if you knew the process wouldn't drag out maybe that'd be inventive to jump in/out quickly.

greggles’s picture

@jredding - thanks for the clarifications.

The EOP must still follow the TOC like all other users on Drupal.org without exception.

I don't see how that's possible. It's an anonymous account whose name reflects an intention for it to be used by an organization. Our registration form says:

Please note: All user accounts are for individuals. Accounts created for more than one user or those using anonymous mail services will be blocked when discovered.

Can you shed some light on that?

jredding’s picture

@greggles See #19. They want the organization to be seen as the developer of the module and the only way to do that now is by creating an organization account and doing initial commits under that account. Development and issue queue management is then done by individuals.

Does that help to understand the issue here?

This problem isn't new to the Whitehouse and it is a problem. It's pointed out in this thread that our TOS needs to be updated and potentially a bit of software configured/written to provide the type of functionality we need. The whitehouse account just provided a brighter spotlight on an existing problem. The Whitehouse, like many, many organizations, wants credit for module contributions so that the organization can demonstrate what they are giving back to the community.

Personally I think this is amazing and something that I believe we, as a community, should encourage more of. My thoughts on this were further underscored this week when I spoke to the organizer of a code-for-Government hack-a-thon in Bern, Switzerland. The leader of that hack-a-thon became more heavily involved in Open Source after the election of Obama and the subsequent moving of the Whitehouse over to Drupal. The PR surrounding the contributions got him to take notice and also gave him ammunition to use in his internal meetings that Open Source is not just a viable alternative within government but it can be the top choice. This is a good thing for Open Source and we need to recognize that it's not just individuals that contribute to Open Source project but also organizations and that contributions committing/contributing to Open Source in a public manner can be a powerful thing.

I gave a suggestion in #19 that would solve this issue for the Whitehouse and many other organizations while requiring no changes to our existing TOS. It doesn't solve the bigger issue of organizations wanting credit for all code contributions on their profile page but that's a bigger and thornier issue.

killes@www.drop.org’s picture

So, I propose the following:

1) I actually have not many problems with organizations having their boilerplate on:

- projects
- their organization node
- their case studies
- maybe posts in "News & annoucements"?

2) But I firmly believe that any such accounts should be excluded from anything else, that is especially

- participation in the issue queue and forums through nodes and comments
- code commits(!)
- probably some subdomains (I personally wouldn't want to deal with an organisation as part of the security process)

3) Since the DA wants these organisational accounts, it will manage them. That is, organizations apply to the DA, the DA collects money, the DA's employees create or mark the account as organizational (or there is an automated process). This needs to be in the open so that is verifyable. No backroom deals please.

4) Should there be any issues with the use of the account, the webmasters' team will simply block it as it sees fit and let the DA sort out the remains.

Since the DA seems to be interested in having organizational accounts, I ask the DA to fund development of code that is part of the drupalorg modifications and makes sure that 2 and 3 are adhered to. I have little faith in organizations and believe they'll try to break any rules.

jredding’s picture

@killes
agreed with 1 & 2

Regarding 3 & 4, I think it's the larger community that wants this type of recognition. The DA is just the sounding board for the requests from the organizations. The DA is reflective of the community and there isn't a separation between "the DA does this and the community does this". The DA should be the community and the community should be the DA.

killes@www.drop.org’s picture

Sorry, not buying.

Your decision to make a private deal with the whitehouse account holders that wasn't discussed with the community at all makes it obvious that there are differences between the DA and the community.

jredding’s picture

@killes As I mentioned in #18 there was no private deal between the whitehouse and myself . The TOS hasn't been modified in regards to how accounts are handled and the Whitehouse has been given no special treatment. It's an assumption made in this thread that they have been given special treatment and are subject to different rules. They aren't.

The only thing that this makes obvious is that the model of management for Drupal.org needs to evolve with the current realities of today.

We have organizations that want to receive a byline credit for the modules they are contributing to the project and there is no current method to get that done except for violating the TOS. As I mentioned this is just a brighter spotlight on an existing issue that has existed for sometime. Personally this is a good evolution for Drupal and for open source. It's a good thing that the Whitehouse is contributing to open source and to Drupal, we should highly, highly encourage this and give them and other governments, institutions, organizations, and companies the ability to flaunt their contributions.

Considering that we agree on #1 & #2 of your post then we probably have agreement on the other thread for their latest project. The people behind whitehouse account should post the code as an individual (not as an org) then once the project is approved the project node will be moved over to the whitehouse account. Correct?
http://drupal.org/node/1948254#comment-7220334

jredding’s picture

Issue summary: View changes

x

greggles’s picture

tvn mentioned a situation where an organization account was used for spam and when contacted they claimed it wasn't their fault. Killes point #4 in comment #28 also deals with this and is a good point. I've updated the original post to include a point about the need of the organization to control the account.

@killes - I appreciate your perspective here. I also see this deal as setting a few precedents I would like to avoid rather than embrace. In particular:

  • No closed-door deals - the approximate details of this are now public and the FBI hasn't knocked my door down (yet). In fact I would argue that things are much easier now that welschp posted explaining what they need to have happen (and no, it's not a cck field for sponsor though that idea might have its own merit).
  • Equal engagement for all organizations/people - letting a single event "pave the way" is great, but the paving has to continue beyond that event so that all organizations can engage in a similar way. I think this could have best been handled by working towards making this private TOS an open topic for discussion and forward progress. The closed-door deal without a corresponding public discussion (even without mentioning who was getting the TOS) feels a lot like "Gina the Genius" from minute 14 of Angie's presentations on contributing.
  • When the DA makes private deals on behalf of d.o it is signing up to get more active in enforcing/managing the queues - not setting policy, but helping out if the private deal results in problems (i.e. the pottery store rule: you break it, you buy it). To say the DA is not separate from the community at the same time the DA makes a private deal separate from the community is...hard to understand.

All that said...I don't want to build a new system for classifying organizations and then restricting their permissions via code. I think a stated policy is fine until we see a pattern of abuse. If we see a pattern we should build something more. We can start with a new component or a new project OR a code-based solution (which would also need a new queue, to move organizations into an organization role).

I do not agree with the first 2.5 paragraphs of comment #31.

jredding’s picture

@greggles Glad that we're closing in on an agreement on how to move forward.

I offered a base suggestion for moving forward, which I think satisfies most of our uses cases minus the edge cases. Adding a field on the project node that refers to the organization node will at least connect projects to the organizations that sponsor them. Then we can allow module maintainers to control the field to either set a sponsoring organization or remove it at their discretion. Considering that organization nodes can be managed by multiple accounts we're also set there as well.

I'm at least glad that we're moving in the right direction and heading towards consensus.

killes@www.drop.org’s picture

" Considering that organization nodes can be managed by multiple accounts we're also set there as well. "

This is not the case.

While I agree that the proposed extra field would be a simple solution, it doesn't really seem to be what is required.

webchick’s picture

So this hasn't really moved in 2 weeks; it feels like what's in the issue summary reflects most of the feedback so far. Are we cool to call this issue fixed?

I spun off #1966218: Infrastructure to support organization accounts to talk about implementation of this feature. Updating the issue summary momentarily.

greggles’s picture

So this hasn't really moved in 2 weeks

I want to be clear that it's somewhat intentional that it was left for 2 weeks. The idea is that in general we say "X is what we should do" and then give people time to provide feedback. If there's no new feedback it's an indication of a coalescing consensus.

pcambra’s picture

Posting some feedback here as I learned about this moving forward just yesterday, sorry.

I'd like to open a question on what happens in the case of multiple organizations managing a single project, this is something that happens when some modules/themes/distros get bigger and bigger and needs more hands on it.

I like what Jacob suggests in #19 as it leaves the door opened to have multiple organizations sponsoring a given project whereas there's a schema or individual maintainers. Creating a relationship between the project and the organization would allow some extra permissions to modify certain parts of the project node.

I also want to raise the risk of having a single company as owner of a given project could discourage other rival companies or even individuals from contributing/assigning tech time to that project and that could drive in forking or just not releasing the code. This might be a hidden risk and it's probably happening already but I think it's definitely there.

greg.harvey’s picture

Also only just discovered this, got pointed here after starting this thread earlier today in response to a client's query about membership (I should mark as a dupe, I guess) - #1988818: UX for Organization Member sign up

Anyway, just to add my two pence, my thoughts are:

  • There needs to be a sense of organisation accounts (seems everyone is broadly agreed on that)
  • There's no real need for organisations to 'own' projects, commit or create project nodes, make group posts, comment in forums, etc. IMHO - I agree with killes there - I want an organisational account for our company, I do not want to use that to interact with the community, there are other, more appropriate channels
  • Organisations only really need to maintain an Association subscription (if applicable) and maintain their marketplace listings - everything else can (and arguably should) stay as it is and once a user has the organisation role they are limited to what an organisation needs to do
  • The d.o message saying you MUST be an individual would need to say if you are an organisation that hasn't declared itself an organisation your account will be removed when spotted, so you CAN be an organisation, but you have to declare yourself as such

For me, that represents the best of both worlds - keeps the site a user and developer community first, but allows organisations to interact with that community at an appropriate level.

greggles’s picture

There's no real need for organisations to 'own' projects, commit or create project nodes, make group posts, comment in forums, etc. IMHO - I agree with killes there - I want an organisational account for our company, I do not want to use that to interact with the community, there are other, more appropriate channels

I partially agree with that (e.g. forum, group posts, commits) but I'm confused that you claim there's no need for any organization to create a project since that was the whole impetus for this thread. Are you saying that organizations who think they need to be the author of a node are confused and we should try to educate them?

greg.harvey’s picture

Are you saying that organizations who think they need to be the author of a node are confused and we should try to educate them?

I'd say so... sorry, I realise I'm posting late in the day, I *totally* see the reason for an organisation user to exist for the DA stuff and potentially for marketplace, case studies, etc. - but projects? Nah, I think that's a bad idea. I actually just went into more detail on #1966218: Infrastructure to support organization accounts as the conversation seemed to have moved on there.

Direct link to comment: http://drupal.org/node/1966218#comment-7387124

greggles’s picture

Anyone following this thread should be sure to read #1966218-34: Infrastructure to support organization accounts as it addresses Greg's comments here.

greggles’s picture

Issue summary: View changes

updated per conversation with tvn

greggles’s picture

Issue summary: View changes
Status: Active » Reviewed & tested by the community

I believe that the first step to coming up with a ToS is to decide what policies our communities want.
Next step is for DA to hire a lawyer to advise on those and draft a ToS based on them.

I believe the issue summary on this post represents that first step and #1863498: Create Basis for ToS to allow organizations to share accounts represents the second.

Moving to RTBC since it's been here without dissent for a while.

greggles’s picture

Title: Create ToS to allow organizations to share accounts » Create Basis for ToS to allow organizations to share accounts

Swift move, I linked from this issue to itself.

Anyway, I think my point on process stands and if we slightly re-title this issue then everything is OK. Right?

gdemet’s picture

This is already in process through the Content Working Group and the Drupal Association:

1. CWG to review and approve proposed process and framework (done)
2. DA staff member to prepare initial draft text (in progress)
3. CWG to review and approve draft (to-do)
4. Draft published for community review (to-do)
5. DA executive director shows draft to the DA lawyer (to-do)
6. CWG updates ToS based on community feedback and lawyer recommendations (to-do)
7. Updated draft published one more time for community feedback (to-do)
8. ToS ratified by CWG and officially published on D.o (to-do)

greggles’s picture

@gdemet, great news! Is there any way for someone not on CWG to know that fact or get updates about the progress through the 8 steps? Is the result of step 1 available for review? Should this issue be marked "fixed" or maybe would you like to repurpose it to be a conduit for updates about those 8 steps?

gdemet’s picture

Status: Reviewed & tested by the community » Active
Issue tags: +drupal.org Content Working Group

Hi Greg - The result of step 1 is that we agreed to steps 2-8 ;-)

Once the working group has reviewed the first draft, we'll post it for community review. I do not currently have an ETA for this, as progress has been blocked by other factors, but I will put it on our agenda for our next meeting.

greggles’s picture

Quick ping for status here?

dddave’s picture

Some movement here would be swell. I am currently advising company accounts not to make commits but cannot point them to a authoritative resource about this.

C-Logemann’s picture

There is now an „Introducing Drupal.org Terms of Service and Privacy Policy“. The limits suggested by killes@www.drop.org (#28) are implemented but also the possibility of tolerating organizational accounts as node owner especially of project nodes. Because this was discussed in this issue I add my extended comment here.

I think users should always be humans especially for responsibility issues so I disagree with allowing shared accounts. But if we want to allow them I think they should not be allowed for owning project nodes. Additionally they should be flagged (maybe not changeable by the „user“ ) as suggested in Infrastructure to support organization accounts. And we need extra processes to handle such accounts in communication, responsibility, legal stuff etc.

My thoughts and arguments:

I understand why organizations want this sharing of user accounts but except of localize.drupal.org this is only for referencing some node types to organizations. In Drupal it’s easy to hide node owners. Also we can build and show references with modules entityreference. The idea of jredding to show sponsor-links (#19) is very easy to realize. And if there is a need for modifying shared content we have modules like nodeaccess_userreference to handle write access to nodes. So there is currently no technical need for organizational users on drupal.org in my opinion. Maybe the localize.drupal.org contribution can also be fixed with our own technologies. When we have such a flexibel content management framework why solving such „symbolic“ references with „organizational users“?

Especially with project nodes we have a sensitive issue. Even without shared accounts the ownership of a project node is a little bit confusing. Currently we show the node owner as the creator of a project (Drupal default). But when the ownership is changing (when the maintainer changes) this information becomes wrong. Maybe the changing of the owner is why a maintainer is leaving a project or Drupal at all. But sometimes because of misbehavior mostly on security issues. And this change can be done because no person or no organization owns a project on drupal.org. With contributing code to drupal.org the community is the owner of a project. This is maybe the most important power of our contrib projects. So please be gentle with changing something there!

The idea that an organization may want special permissions to change maintainers or something is completely against transparency. And this transparency in public issues is one of our best community tools especially if the maintainers of a project having trouble. Even without special permissions the ownership of project nodes by organizational users can be against the contribution of other people or organizations. I agree with pcambra on comment #37. I think we need other ways to show contributions of organizations. Until we have a better solution I think sponsoring information on project nodes as it's currently used on many projects is still a good compromise. But sponsor-links (#19) are better than organizational users as owners of project nodes.

I believe that more companies and other organizations using Drupal should be more involved in the community. But this can only be done with persons. And when an organization has leaders I hope this leaders are personally supporting the Drupal community and maybe accept our rules like our DCOD. I think the DCOD should be accepted by persons and this should maybe be done with a field in user accounts. And even if the leaders of an organization will accept the DCOD where this should be documented? Who is allowed to create and maintaining an organizational account and all the other questions coming up with this possibility? I think there is more to be ruled as only disallowing code commits, comments etc.

An organization itself can’t create a node because it can’t do something without humans. In Domain registrations an organization can be the „owner“ of the domains but for administrative issues there have to be persons as contact handles to be responsible and to maintain things.

It’s hard enough to get the people of our community work together. There are already some arguments about communication problems with shared accounts. Where is the solution of this problems? In my personal opinion the reality is that many leaders of companies and other organizations didn’t understand open source and its communities. I think allowing organizational users for such organizations won’t help them to improve but cause problems in our community.

(I hope everybody of can understand my arguments. English is not my native language and arguing about social things is harder for me than talking about technical things.)

catch’s picture

Yeah I really don't see the advantage to allowing organisations/companies to own project nodes, there's already a system for transferring maintainership between individuals in Drupal.org, and 99.9% of the time the node owner doesn't make any difference. The only argument I can see for having it at all is for when individual developers leave an employer? The history of lots of modules shows that this doesn't necessarily mean the developer stops maintaining a specific module, and similarly it also doesn't mean that the original employer continues to maintain the module either.

Adding or removing co-maintainers on a project needs to be accountable - right now you know that only other co-maintainers as individuals can do that, or someone with the required permissions on d.o - both of these are very controlled groups. With a shared account there's no accountability at all.

greggles’s picture

With a shared account there's no accountability at all.

I think that's addressed by this bullet point in the current issue summary:

The organization is 100% responsible for the security and use of the account - if it is used inappropriately (e.g. spam, posting ads in the hosting forum) it will be blocked the same as any individual account will be blocked.

catch’s picture

If the account can be used to grant commit access to projects, then the consequences of a generously shared password could be worse than spam or ads.

greggles’s picture

That is a risk, but I don't see how its much worse than today where many maintainers give out access quite readily:

https://www.drupal.org/node/18723/maintainers
https://www.drupal.org/node/19304/maintainers

You can argue that with a shared company account as an owner it's likely to be worse and in some cases that is probably true, but it's just conjecture. In the situations we've seen so far, the company-as-project-owner hasn't given out more permissions than normal.

C-Logemann’s picture

Even if the "The organization is 100% responsible for the security and use of the account ..." it isn't transparent to the community who is deciding inside this organization.
And how we can prove that an organizational account is (still) managed by this organization? We also cannot see which person is using the shared account.
Especially if a real person disagree with some operations of a shared account what can (s)he do? How to try a personal discussion maybe in IRC? And there are some minor problems about contacting an organization maybe with the contact form on a shared account. How to address a question? With "Dear Sir or Madam ..."?
It's not only about conflicts and misbehavior. Communication of real people we can meet on Camps, Cons or IRC is powering our community.

webchick’s picture

That's why organization accounts are strictly forbidden from "communicating" at all. They're only allowed to "own" nodes of a very specific type, but their individual employees are the ones who do the commenting, issue posting, committing, etc.

So presumably if you had a problem with a project that was owned by an organization, you would file an issue, same as you would with a project owned by an individual. And if that wasn't responded to, you would find the person who last committed code to the project and contact them via their contact form, same as you do with a project owned by an individual.

greggles’s picture

re #54, again, how is that any different from what many individuals do now? I've seen plenty of rather opaque and frustrating maneuvers on the part of individuals. And as webchick pointed out in #55, filing an issue in the queue and maybe using an individual's contact form helped resolve them. I don't think that the company account will make this problem any better or worse.

C-Logemann’s picture

I think direct communication is often a good way to cooperate. But it's right that issues can still be used for communication.

As I know currently we do not allow shared accounts and there are only some exceptions we tolerate. In my opinion the "behavior" of this tolerated shared accounts is not enough data for an extrapolation of the behavior of many shared node owners in future which are officially allowed. I believe that there is a risk of problems for a "feature" we don't really need (as described above).

joshuami’s picture

Assigned: Unassigned » joshuami
Status: Active » Fixed

After months of working out the language, organization accounts are now officially supported in our terms of service:

3. If you are sharing your user account with multiple people (e.g. as your “official” organization account), you are not allowed to do the following using this account:

  • commit code to Git repositories on the Website
  • create any nodes except for organization, case study or project nodes
  • comment on nodes

If you are sharing your user account with multiple people you ARE allowed to:

  • create project nodes
  • create organization nodes
  • create case study nodes
  • submit translations to localize.drupal.org

I'm closing out this issue as fixed, but we are open to further feedback as this goes into general usage.

greggles’s picture

Thanks so much to you and everyone involved in the process of getting that live!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.