Social Speech

There are some errors reported by automated review tools, did you already check them? See http://ventral.org/pareview/httpgitdrupalorgsandboxwhitehouse1945892git

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

I took a quick look through the repository tonight ... the code is clean, well documented, and the PAReview script reports no errors. Only a few comments:

• I might suggest creating a dedicated permission to control access to the /admin/settings/social-speech form (instead of the current 'administer site configuration'), in order to allow more granularity when assigning permissions to roles ... but that is simply a personal preference.
• On line 510 of social_speech.module:
  $tokens['social_speech_abbreviations'] = t($abbreviations, $vars);
  Because a variable is being passed into t() here, automated translations tools will not be able to extract the string and expose it to translators. To facilitate translation, the string can either be placed directly into this t() call, or can be included in a dummy file that passes the relevant string through t() (as discussed at http://api.drupal.org/api/drupal/includes!common.inc/function/t/6, about halfway down the 'Examples' section). Passing variables into t() can also have performance implications over time in certain situations, also discussed at the above link.
• In addition, the use of $vars in the above function appears redundant, as the only function calls referencing it explicitly pass an empty string or empty array as the second argument. I believe it could be removed.
• As a best practice, I'd suggest adding a hook_uninstall() routine which deletes any variables belonging to the module (e.g. 'social_speech_abbreviations' and 'social_speech_twitter'), and refreshes the variable cache when the module is uninstalled.

Other than the one errant t() call, I don't see any major showstoppers; and wouldn't hesitate to recommend this application for promotion.

IMO it's not appropriate for an organization account to commit code. I'm fine with an organization owning the project node. I think the individual(s) using this account should apply individually and then be granted committer access on the project (or just granted access without git vetted user since the individuals don't necessarily need that to contribute to a project).

I agree with greggles. Our current policy on user account states that all user accounts are for individuals. Accounts created for more than one user will be blocked when discovered. I assume your account is to be used as group account?

Furthermore I don't feel comfortable interacting with an institution in the issue queue, especially such a high profile organization as the US government. Who is behind the account and who am I speaking with, is it you Barack? I think drupal.org should be a neutral and same level playing field, and I can imagine that people are afraid to freely speak their mind when communicating with the whitehouse.

Note: I'm fine with very small Drupal shops that use their company/organization name as user account on drupal.org to promote themselves, as long as it is clear that a single person is behind it. For larger organizations it does not make sense.

I can see that the whitehouse wants to establish a presence on drupal.org, but I think it should be done with a profile page like that of my company for example: http://drupal.org/marketplace/epiqo . It allows us to clearly state our objectives + contributions and also lists the members nicely. Our community is about humans and individuals and I think organizations should be in their background.

So here is my suggestion:
* Rename your user account to something more personal, so that it is clear that an individual is behind it. That account will not be passed on and only you yourself should use it.
* Create an organization profile page for the whitehouse.

Question: does the whitehouse forbid their employees to commit code or have user accounts on drupal.org for work purposes?

So we need some more information here before we can continue. It might be a good idea to also get the opinion of someone from the Drupal association or Dries on this issue.

Hm, I just found #1863498: Create Basis for ToS to allow organizations to share accounts. So it seems the whitehouse has some special deal with the Drupal association, but there is no information published about this?

we need to support organizations in releasing code -they have to overcome enough road blocks to be able to do this. especially one like the WH. it is unfair to hold them up while we work out and better publicly communicate our policies independently... it is not like this is the first time we are allowing the WH or others to release code under such an account, and it really does a disservice to Drupal to be the bottleneck here.

i generally agree with greg, that it'd be ideal to have an individual contact for the code, but there are some organizations that might not be able to publicly identify an individual - i'd imagine WH is one of these orgs... we need to figure a proper solution that meets the needs of organizations and the community, and i don't think it is an easy or quick answer.

while Drupal has one of the largest and most active development communities in the world, the number of contributors is <1% of the actual users, and there are few enterprises and large organizations participating directly ...the project would be even more successful if we can find a way to foster this participation. i'm willing to work out a solution to the larger problem with organizations, the community, and the DA... but can we move this forward in the meantime please. thanks _m

I appreciate and certainly agree with the goal of making it easy for orgs to release code. I don't think that means we should just ignore community norms and policies.

This actually *is* the first time the WH is officially getting permission via the proper channels to release code on d.o. They previously used a bit of an "end-run" around the proper process to create modules and release code (it's a commonly used end-run and they haven't abused it the way others have - I don't hold it against them) . I very much appreciate this application, but feel it's putting the cart in front of the horse. If we don't bottleneck it here...where should we bottleneck it? Technically the right thing to do is to simply block their account - it exists contrary to community policy. The fact nobody has done that shows a fair bit of restraint.

You've made a guess at a reason the WH might want to commit code as an organization rather than individuals: the need for privacy/obscurity in who is working on the site. If the Whitehouse is trying to hide the identities of the people working on their website they are doing a pretty poor job (I'll leave out the specific details of how I know this for now, but let's just say anyone anywhere in the world can figure it out with about 5 minutes of research). Given the evidence to the contrary, I don't think that's a very likely reason for an organization not to commit code. How about we wait for people to say why they aren't contributing and adjust policy in ways that respect that AND our community's norms and policies.

I welcome your interest in this area. I agree it's somewhere that needs to be made a welcoming area for all sorts of contributors. There's a ton more on where this process came from and where it's going over at the code review group. I agree it would be amazing if we can work (probably there) to get to >1% of Drupal's users contributing back.

While I don't share as strong an opinion on the subject, I can see the danger in setting a precedent with regards to 'corporate' commits; which, when you extend it beyond the circumstances of this particular account, comes uncomfortably close to 'anonymous' commits.

While we do not want to delay applications while debating whether we need a change in policy; this application can't be approved under the policy as it stand today ... at least not without granting it an explicit exception. Any such exception needs to come from someone acting in a more 'official' capacity than the volunteers currently supporting this process, so as to prevent it being seen as i) a precendent to be leveraged by others seeking a corporate account, or ii) a policy change that hasn't first been reviewed and veted by the larger Drupal community.

So as a next step, I'd suggest we confer with the Drupal Association to determine whether code commits fall within the scope the negotiated agreement with regards to this account ... and/or the account owners designate an individual whom they wish to associate with this particular application. Keep in mind, once approved, a 'git vetted user' can add whomever they want as co-maintainers (and thus committers) on any of their projects, regardless of whether those co-maintainers themselves have the 'git vetted users' permission or not.

I don't think this would be a precedent. Eg. http://www.icanlocalize.com/site/ vs. http://drupal.org/user/354398 predates several years. I don't think it makes sense to accept the "end-runs" (eg. creating a project by a vetted human and then transferring to organisation accounts) that has happened before but not accepting the direct creation is enforcing policy anyway. It is just making it look like we are tough guys but then looking away. I personally think showing we are nice guys overall is better.

I also find it puzzling that we'd go to the Drupal Association to discuss who do we give certain commit privileges. To my best knowledge, the association was set up specifically not to be able to dabble in code matters on that level.

Quick reminder to folks contemplating weighing in that when you weigh in on an issue in the queue and have a current or future business relationship it is appropriate to mention that as a potential source of bias.

(I'm personally not involved with either icanlocalize or whitehouse. Companies I worked for might have been involved at one point or another).

BTW, anyone who wants to move the broader issue forward should discuss in #1863498: Create Basis for ToS to allow organizations to share accounts.

I also find it puzzling that we'd go to the Drupal Association to discuss who do we give certain commit privileges.

In general, I agree. I mention it here from the perspective that there may be a pre-existing discussion/agreement with regards to this account, and only those who were involved in that discussion know the true details.

Hey guys -

Just wanted to let you know that we are aware of this conversation. This situation pre-dates me, so I need to get up to speed. Give me a bit of time to do that, and I'll get back to you.

Holly

Hi all -

FYI that Dries and Angie will be responding when they have had a chance to review.

Best,
Holly

@Gábor Hojtsy

Re: #13

To clarify,

In your drupal.org user profile, Acquia is listed as your current employer.

In the disclosure at the bottom of this post, it is stated that Acquia was involved with the development of whitehouse.gov.

Your current employer was involved with the development of whitehouse.gov. I'd qualify this as a business relationship, and I'd argue that this relationship, as @greggles stated, is "a potential source of bias".

*I* was certainly never involved in any projects with the white house. I am happy to be out of this thread, I contributed as much as I thought was valuable. My career certainly benefited from any high profile Drupal projects in the last decade from around the globe, as with most everbody making money working on Drupal in and out of this thread.

@greggles and @klausi I think these are very reasonable requests and I'm sure the whitehouse team wouldn't have a problem with that (i.e. initial commit done by an individual developer and the project node moved to an organization account such that the project node is seen as a Whitehouse module).

I posted additional information on this situation here: http://drupal.org/node/1863498#comment-7219566

If I understand correctly to move forward on this thread @greggles and @klausi you would like:

1) The responsible developer on the @whitehouse team to post the code under their individual account
2) Once the code passes the project application approval process the project node will then be moved back under the ownership of the @whitehouse account. Someone on the D.O administration team would make this transfer.

Is that correct? Would that unstick this issue and allow this project to move forward?

We can then move drupal.org policy and process discussion over to: http://drupal.org/node/1863498

Hi all – my name's Pete Welsch, I work with the White House Office of Digital Strategy and am part of the team that would be contributing code from the whitehouse account.

First, thanks for taking a look at this project. Thank you, too, for your openness to discussing how the White House might take part on Drupal.org.

A good example of how we hope to use the whitehouse account can be seen on GitHub here, where the WhiteHouse "organization" owns each project, but individual "members" (like maintainers on drupal.org) make commits, accept pull requests, and interact with the community. (At one point @jenlampton suggested considering GitHub's approach here.) We'd be approximating that use case with an organizational account that owns projects while individual maintainers handle commits.

In order to participate on Drupal.org, we need to meet a number of legal requirements and this approach addresses several of them. One of the most important is that it facilitates compliance with the Presidential Records Act, which is of critical importance for us. It would also help ensure that the White House can continue to maintain and be clearly responsible for these projects over the long term. As more government departments and agencies start using Drupal, shared organizational accounts like this could make contributing back to the Drupal community much easier for them and, in some cases, be the difference between simply using Drupal and actually helping it grow.

For now, we'll stand back and let the community sort out the best path forward. We hope that the whitehouse account will be able to post and own projects soon. Until then we'll keep posting code, either on GitHub or as sandbox projects here.

Thanks again for your consideration.

Hi welschp, Thanks for your comment. I think this is basically ready to go.

• I propose that we change this application to be about giving the welschp account the git vetted user role. My sense from comment #21 is that you are responsible for the code in this application.
• Then, the whitehouse account can create the Social Speech project as a sandbox and add welschp as a maintainer with full permissions to edit the project
• Then welschp will have the ability to promote the project to a full project and make the individual commits

I just tested this process with amateescu (someone with "git vetted user" role, but no roles that are more powerful). I created a sandbox and he promoted it to become a full project.

@welschp - if you agree with this proposal please comment here (ideally via someone using the whitehouse account, since the application was opened under that account) indicating that it is appropriate for this application to be about the welschp account. Then it can go back to Ready To Be Committed for you and probably get "fixed" pretty quickly.

I believe this removes allows the whitehouse and individual contributor accounts to engage with drupal.org in a way that is consistent with what the whitehouse legal team needs, what drupal.org's normal user policy promotes, and what we know of the whitehouse specific terms of use allows. It is also consistent with the proposed policy in #1863498: Create Basis for ToS to allow organizations to share accounts which isn't yet approved, but has support from a fair number of folks.

While I personally do not think there's any problem with an account for an organization currently http://drupal.org/user/register 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.

We need to change that first.

Edit: I didn't realize #1863498: Create Basis for ToS to allow organizations to share accounts was about this.

Everyone seems satisfied with the current plan, and it does seem like a good solution. We do need to get an Org set of special TOS/Policy, but we are in a DoOcracy on here, so let's take the first step in getting it started. The rest of the conversation is over in #1863498: Create Basis for ToS to allow organizations to share accounts and seems to be a work in progress.

That just leaves me to review the code, which is clean and well commented so that makes things way easier than normal. And by the looks, it will be potentially archived by the Presidential Records Act. Eeek. Some quick notes:

Reducing a hash algorithm is A Bad Thing™

    // Create a unique SHA1 hash for this sentence. We only grab the first
    // 8 characters of this string, which should remain fairly unique.
    $hash = substr(sha1($sentence), 0, 8);

sha1 returns a 40 character string, which means this has removed 99.99999(insert more nines here)9999% (or 100 - 2.9387359e-39) of the hashspace, vastly increasing the likeliness of a collision - 4,294,967,296 possibilities instead of 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 (try saying that 3 times fast, or once). It may seem rare, but depending on how many hashes/sentences there are the chances of collision go up a lot. If it's important to have an unique hash, why not use the full hash space? 8 vs 40 chars is nothing.
If it's only important that the hash be unique on each page, then keep a record of which hash (or substring of a hash) has been used on the page/theme/run so far, and if there is a collision adjust it so there isn't. The 8 char substring could still be used for less than 4 billion items per page ;) The hashing becomes mute and they should just use a sequential number.
From some other parts of the code, the hash is indicated to be unique over all sentences rendered on all pages? (comment on social_speech_webform_submit). If this is the case, for a site like the whitehouse, surely there would be more than 9200 sentences ever? This is the number of 8 character substring hashes needed for a 1% chance of collision with the birthday paradox. 77000 for 50% chance, and it just goes up from there. (someone smarter than me figured those out)

social_speech_abbreviations directions

The admin is not told that the delimiter is a newline. It will be caught by the regex, but may as well tell people that it expects one abbreviation per line, followed by a period. With no blank lines above or below.

Delete variables

When uninstalling the module, it should remove not only the schema, but also all the variables it used. eg. social_speech_abbreviations. variable_del for a few, or DELETE + mimic cache flushing done by variable_del if there are lots of them.

Telling the right person about the requirements

Hook requirements is currently set to check on runtime if the Simple HTML DOM library is present. Any time the module attempts to render an element for it, it tells the end user (not admin) that it's missing. Using install and runtime would mean that the admin would have to have it installed to start with. Could also probably get away with not telling the end user about the error as it's completely useless to them.
Ditto for jQuery 1.8.3 in the social_speech_webform module, but this one doesn't tell the end user there is an issue.

validation

The fields added by social_speech_webform to webform seem to require very specific formatting, but make no effort to validate that. eg ".bt-wrapper form input[name=submitted[sentence_id]]".

None of those are blockers or security issues, so here goes the template.

Thanks for your contribution, Whitehouse/Pete Welsch! Welcome to the community of project contributors on drupal.org.

I've granted welschp the git vetted user role which will let you promote this to a full project and also create new projects as either sandbox or "full" projects depending on which you feel is best.

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

That's great - thanks very much, @ELC. Social Speech has been promoted to full project status.

I'm wondering if the Social speech module could be implemented for Corporate portals and what's about new releases an updates? Itransition company will support the initiative of Social Speech.