Page MenuHomePhabricator

Use the term "developer account" for Wikimedia LDAP accounts
Closed, ResolvedPublic

Tokens
"Mountain of Wealth" token, awarded by Daegontaven."Party Time" token, awarded by D3r1ck01."Meh!" token, awarded by MichaelSchoenitzer_WMDE."Like" token, awarded by Mholloway."Meh!" token, awarded by Addshore."Love" token, awarded by Neil_P._Quinn_WMF."Like" token, awarded by Jdforrester-WMF."Like" token, awarded by Smalyshev."Like" token, awarded by Harej."Like" token, awarded by Zppix."Love" token, awarded by faidon."Love" token, awarded by madhuvishy."Doubloon" token, awarded by Volker_E."Piece of Eight" token, awarded by Prtksxna.
Assigned To
None
Authored By
bd808, Nov 1 2017

Description

Sometimes our docs say "Wikitech account". Sometimes they say "LDAP account". Sometimes they say "Toolforge account". Sometimes they say "Labs account". All of these are the same thing, but how would anyone new (or even not new) to contributing know that?

What we are talking about here is same sign-on credentials that can be used to authenticate to:

I think we should standardize on the term "Wikimedia developer account" ("developer account" in shortened form) for this set of authentication credentials.

There is a case to be made for "technical contributor account" as "developer" could be seen as excluding/discouraging contributions which are not strictly "development". The downside of this that I can see is that it shortens poorly. People will shorten any and all phrases that are used often. "Dev account" is still relatively recognizable, but "TC account" is not in my opinion.


[Announced on wikitech-l on 2018-02-23. Proposed to evaluate discussion for consensus and approve/deny on 2018-03-23.]

Event Timeline

bd808 created this task.Nov 1 2017, 3:13 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 1 2017, 3:13 AM

+1. Another term to sync: "Developer access". Related: Any recommendation what the term should link to? Directly to https://wikitech.wikimedia.org/wiki/Special:CreateAccount or some explanation page somewhere inbetween?

bd808 added a comment.Nov 2 2017, 3:40 AM

Related: Any recommendation what the term should link to? Directly to https://wikitech.wikimedia.org/wiki/Special:CreateAccount or some explanation page somewhere inbetween?

I think it would be reasonable to invent some interstitial page. Today there two different paths that could be followed by a user to create an LDAP account (wikitech.wikimedia.org and Striker). The wikitech path will go away ifwhen T161859 finally happens. The replacement is currently unknown. There is one proposal in rough form at T179463: Create a single application to provision and manage developer (LDAP) accounts which may or may not ultimately be the canonical location for creating and managing these accounts. If we have an interstitial page on mediawiki.org, wikitech, or even metawiki we have a way to consolidate instructions and links in one place.

Prtksxna added a comment.EditedNov 2 2017, 4:20 AM

Developer account surely sounds less intimidating than Toolforge account or LDAP account. However, as you mentioned in the description, it might be intimidating for a designer, bug reporter etc. I do think that this notion is slowly changing with developer/code to mean anything that is involved with making a project (not saying its good, just saying its happening). For example Google Code-In allows design and research tasks.

This is surely an improvement and consolidates terms. Do you want to set a deadline for brainstorming?


Ideas

  • Contributor account (not to be confused with the contributors department)
  • MediaWiki Hacker account 😝
  • Wikitech account is nice but might be taken in the narrow sense of just that wiki
chasemp added a subscriber: chasemp.Nov 2 2017, 1:52 PM

+1 to Wikimedia developer account (or developer account for short)

Reasons other options are less-good:

wikitech account - we don't want people to sign up via wikitech long term. Ideally wikitech becomes SUL and independent of LDAP.
LDAP account - It's unclear to nearly everyone :) what is tied into LDAP, why that matters, and if we are going to bother solidifying on a standard let's not make it implementation specific.
Mediawiki account - As ambiguous as, or more than, LDAP account, etc
Toolforge account - Way too granular and lacking the right context.
Labs - Account. Please no. ;)
Cloud account - confusing as most production administrative services such as graphite, grafana, ELK, use the backend.

Volker_E added a subscriber: Volker_E.

+1 to “Wikimedia developer account” (or “developer account” for short)

Reasons against other options:
“Contributor account” – too distinct Wikimedia Foundation internal term with only little visibility outside Foundation
“MediaWiki account” – as much as this would be a broader understood term, by far not all things done on Phabricator/Gerrit are MediaWiki bound
“Wikitech account” – too slangy again, too little visibility

Legoktm added a subscriber: Legoktm.Nov 2 2017, 6:01 PM

(Wikimedia) developer account sounds good. For short it can be abbreviated to DUL: Developer/Designer/Debugger/etc. Unified Login, which compliments SUL.

Tgr added a subscriber: Tgr.Nov 2 2017, 8:43 PM

Is this a long-term problem or a temporary one? Wikitech will switch to SUL, Phabricator is already working with it, are there plans to move more things?

Few of our LDAP-protected services are actually available to random (non-NDA-d) developers so not sure of saying "you can use it with your developer account" will reduce confusion.

If you want to go with technical contributor account, it shortens nicely to "tech account". I wouldn't say that designers aren't developers though. Dictionary.com gives the meaning of the word as a person or thing that develops or innovates and that describes a designer or product owner or documentation writer or constructive bug tracker participant just as well as a programmer.

LDAP account - It's unclear to nearly everyone :) what is tied into LDAP, why that matters, and if we are going to bother solidifying on a standard let's not make it implementation specific.

Also WMF staff have another set of LDAP accounts for work email, office wifi etc which can result in lots of confusion.

bd808 added a comment.Nov 2 2017, 9:57 PM

Is this a long-term problem or a temporary one? Wikitech will switch to SUL, Phabricator is already working with it, are there plans to move more things?
Few of our LDAP-protected services are actually available to random (non-NDA-d) developers so not sure of saying "you can use it with your developer account" will reduce confusion.
(...snip...)
Also WMF staff have another set of LDAP accounts for work email, office wifi etc which can result in lots of confusion.

I think you have asked and answered your own question here. Wikimedia wiki accounts are not shell accounts. MediaWiki is also not a good single sign-on provider platform. We are abusing OAuth as an authentication provider for Phabricator, but that is not the strength of the OAuth protocol. As long as we have shell access and other things that are not wikis we are going to have a need for "another" account that can grant access to these systems. I can imagine a future where its less of a split and more of a "attribute" that is added to a SUL account. That's the direction that Striker is trying to take things and what I would suggest as the design for account creation in T179463: Create a single application to provision and manage developer (LDAP) accounts. Even then the "attribute" will need a name.

If you want to go with technical contributor account, it shortens nicely to "tech account"

That is a better short form than the "TC account" I imagined.

In the big picture, I don't care what the name is. My criteria are just that it not include "Wikitech" (that's a wiki for system administration documentation) or "LDAP" (that's an application protocol for accessing and maintaining distributed directory information services). The next level of consideration is more about derivative naming for things like the application that is used to provision and manage the accounts; "Go to https://$SOMETHING.wikimedia.org/ to setup your $SOMETHING account".

Tgr added a comment.Nov 2 2017, 10:32 PM

MediaWiki is also not a good single sign-on provider platform. We are abusing OAuth as an authentication provider for Phabricator, but that is not the strength of the OAuth protocol.

(Well-actually sidetrack: AIUI we basically implemented an OpenID Connect lookalike on top of OAuth 1. Homegrown security solutions are never great but the usual "do not use OAuth for authentication" warnings do not apply; that isn't what we are doing.)

Qgil added a subscriber: Qgil.EditedNov 3 2017, 4:35 PM

"Wikimedia Developer account" sounds very good to me. A good complement to the "Wikimedia account" (SUL, non-tech). Thank you for consolidating and clarifying labels!

While non-developers may get a Wikimedia Developer Account, still the main purpose of these accounts is to provide services for developers. I think the concession is fine.

faidon awarded a token.Nov 6 2017, 3:04 PM
faidon added a project: Operations.
bd808 added a comment.Nov 6 2017, 3:43 PM

(Well-actually sidetrack: AIUI we basically implemented an OpenID Connect lookalike on top of OAuth 1. Homegrown security solutions are never great but the usual "do not use OAuth for authentication" warnings do not apply; that isn't what we are doing.)

/me takes the bait.

We do have a solution that allows an OAuth connected application to get identity information including wiki group membership for the connected user. This is a non-standard, invented here solution. As such it requires custom code to integrate into any 3rd party application that may want to use Wikimedia (or MediaWiki) accounts for authn/authz. This need for a completely or at least mostly custom integration makes the workflow of limited use. We would be much better served by implementing a standard SSO protocol which would have native integration or at least non-MediaWiki specific plugin support in platforms like Apache, Nginx, Phabricator, Discourse, etc that may have a use case for single/same sign-on with Wikimedia accounts. I have not done research on this class of problem of years, but SAML, OpenID, and true OpenID Connect are some of the available APIs in this space.

Further discussion of this side topic should probably fork into its own ticket about the need (or lack of need) for more user and developer friendly authentication and authorization integration for 3rd party applications with MediaWiki as the authoritative data store. This may be a problem nearly exclusive to the needs of the Wikimedia movement as several solutions exist for the enterprise and 3rd party market to go the other direction and provide authn/authz for a MediaWiki deploy based on an authoritative external source.

Zppix awarded a token.Nov 8 2017, 7:55 PM
Harej awarded a token.Dec 21 2017, 7:17 PM
bd808 updated the task description. (Show Details)Feb 23 2018, 8:59 PM
bd808 updated the task description. (Show Details)
Harej added a subscriber: Harej.Mar 5 2018, 9:53 PM

@bd808 emailed wikitech on February 23 asking for input.

Unless serious objections are raised, should we consider it a done deal by March 23?

Quiddity updated the task description. (Show Details)Mar 23 2018, 5:03 PM
Quiddity closed this task as Resolved.Mar 23 2018, 5:14 PM

Closing as resolved, with agreement to follow task title recommendation.

Change 467723 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[operations/puppet@production] apache basic auth: Use term "developer account"

https://gerrit.wikimedia.org/r/467723

Change 467723 merged by Filippo Giunchedi:
[operations/puppet@production] apache basic auth: Use term "developer account"

https://gerrit.wikimedia.org/r/467723