I've helped lots of newbies at editathons and elsewhere, and I agree that getting rid of unnecessary barriers is a worthwhile tactic. One of the barriers that weighs heaviest on our best new editors is the capcha process when you add links. It should be fairly easy to amend that process to whitelist certain websites that are known as reliable sources. We can mitigate this at editathons if we have an admin on hand, but our admins are getting fewer. We need to reduce our dependence on them
Talk:In-context help and onboarding/Flow
Thanks for your tip @WereSpielChequers. You cite the " the capcha process when you add links." I want to be positive I know just what you're referring to. Can you say more about when this happens and what happens? Thanks again!
For IP-editors and new-accounts (i.e. non-"autoconfirmed"), if their edit adds an external link, then they're required to solve a captcha before they can save the edit. Screenshot example where I've tried to add http://www.example.org to the page and save it.
(Captchas are also required when creating a new account.)
Admins are involved, because they can add the user-group "confirmed" to an existing account, which gives them the user-right "skipcaptcha".
We use extension:ConfirmEdit, and the "FancyCaptcha" module within that extension, on Wikimedia wikis. There is already site-whitelist functionality in that extension, described at Extension:ConfirmEdit#URL_and_IP_whitelists but the list on Enwiki is very short: https://en.wikipedia.org/wiki/MediaWiki:Captcha-addurl-whitelist. I don't know if there are already more complete lists of "known as reliable sources" sites that we could/should add there?
The list has just been GREATLY expanded and a process put in place to review new additions as proposed.
Thanks Quiddity, that about describes it. I've helped out at outreach events and appointed newbies as confirmed to reduce this problem, and I've made some suggestions on EN wiki. There are other problems such as the maximum number of edits per minute, but most people doing outreach know not to structure events along the lines of "all hit save now".
So I see a few different issues here. Among them:
- #1 The capchas are confusing to non-English speakers. This is captured in T7309
- #2 The capcha that comes up (under certain conditions?) when edits include a link—as documented in Screenshot example—includes messaging that is very confusing, IMHO.
- #3 Related to that, it seems likely that not enough sources have been added to the whitelist that would, I gather, preclude the capcha from appearing.
My initial reaction is that I'm not sure any of these are in-scope for In-Context Help and Onboarding, which is about providing better information to new users. Another layer of popup information on top of this Screenshot example would not, in my opinion, be welcome or helpful to a new user. So what can be done?
There is a ticket for #1. The issue there seems to be that, in the ticket's 10-year history, no one has made it their responsibility to address it. Do we know who this should belong to by rights? Is it something the communities involved can fix themselves?
Then, I'm wondering, are there tickets for #2 and #3? Could we write some? I still don't understand what the conditions are that cause #2 to happen. It doesn't, for example, come up every time a user adds a reference. When does it come up? What is the actual purpose of the function?
And re. #3, aren't there whitelists of reliable sources? E.g., this Spam Whitelist. Why not add the sources here or on other approved lists to the capcha list?
If there's bad information being presented then I'd have hoped it was in scope to replace that with better information. Remember much of our problem is distraction and unnecessary complication, so adding extra information is rarely going to be helpful. We need some of the existing information to be replaced with better information, or more accurately targeted information. Also the big problems with capchas are that they break people's flow of thought and distract them.
For #1, the extension/task belongs to the Editing team (or interested volunteer devs). The non-developer communities cannot do anything to help, at this moment.
For #2, I agree the messaging is confusing. That's the drawback of documentation-by-committee/random-participants! For the default string, anyone can write a task to change the wording in the i18n file. However, for English Wikipedia, they've overridden the string at w:en:MediaWiki:Fancycaptcha-addurl and it would either need to be updated there, or deleted locally in order to use the extension's default.
For #2, I believe it does (or should) ask for a captcha when adding references with external links. You can test with a new account at w:en:Wikipedia:Sandbox. (I managed 1 edit without a captcha, but I suspect that was simply a bug? All my other tests resulted in captcha-requests.)
For #2 and #3, the confirmedit extension was primarily/originally created to prevent bots from spamming wikis.
For #3, the spam-whitelist is only meant to be used for specific pages within a blacklisted site, and is not a list of reliable sites.
For #3, I see that WereSpielChequers has already proposed some additions at Enwiki's captcha-whitelist. However there are many thousands of potentially reliable sites (none of which are guaranteed reliable on every page, nor on every topic, and all on a spectrum with subjective fuzzy-lines) so making a complete list would be a massive endeavour. I don't think there are additional whitelists of reliable sources, beyond the small handful of lists in w:en:Category:WikiProject_lists_of_online_reliable_sources some of which are mis-categorized there.
Hope that helps!
I suggest drawing a fairly sharp distinction between "in-context help" and "onboarding". The vast majority of users would benefit from in-context help, if that answers either "What does this specific feature [of VE, primarily] do?" or "How do I do this [in VE, primarily]?" By contrast, onboarding is (by definition) for new(er) editors, and its focus is on different things: "How can we help you do something useful, rather than futile?", "Here is a policy or guidelines that you don't seem to be aware of?", and similar.
For in-context help:
(a) Some time ago I suggested adding clear, helpful information to all of the editing options in VisualEditor. That followed a limited attempt to do so by the WMF developers - see, for example, in the page options menu, when "Options" is selected, the small "i" with a circle around it, on the right side of the dialog box. The critical parts of implementing such a system, I believe, are (a) adding "hooks" in all the right places (the small "information" icons), (b) enabling administrators of local wikis to add and edit the displayed text [raising translation/maintenance of "core" message issues, but I digress], and (c) enabling those administrators to add links within the text, so those more inclined could go to help and/or guideline pages.
(b) For "How do I do this", it could be very helpful if the Help icon in VisualEditor allowed an editor to select from (say) 50 to 100 different choices ("How do I add a footnote?"; "How do I cite the same source in more than one place in an article?"; "How do I add a category to an article") and, then, in the best of all possible worlds, see a brief screencast showing exactly how to do that thing.
There is, unfortunately, a larger issue. I'm sure that WMF sees the challenge as designing tools for in-context help and for onboarding, and then letting the community use these. Unfortunately, the English community (among the most active) has demonstrated, convincingly (in my opinion), that it's incapable of maintaining help pages - "maintaining" in the sense of "keeping current with the software changes that developers implement". For example, I'd give good odds [without having looked] that the vast majority of help and info pages for editing don't give at least equal weight to VisualEditor compared to the classic wikitext editor - yet WMF is in the process of introducing yet another type of editing software.
There is a solution to this problem, which I mention for the sake of completeness: WMF should take responsibility for core documentation, including in-context help, and including translation, for user interfaces. In other words, where WMF provides cross-wiki functionality, it should provide cross-wiki documentation. (Policies, guidelines, and processes that are wiki-specific would remain fully the responsibility of the local wiki to maintain.) Assuming that additional responsibility would cost WMF on the order of several million dollars a year [more to start, less ongoing], money that WMF clearly has. That wouldn't eliminate the role of the community in improving in-context help and other documentation management by the WMF; the community would have a supplemental role (as in, for example, "feel free to edit this to improve it").
Hello John
Concerning communities that take care of documentation, French Wikipedia has made a strong effort to have help pages for both wikitext and visual editing. See to insert a citation, with wikitext (the simple version, there are actually 2 other pages with an increasing difficulty!) and VE (one page, and that's all).
That community effort concerning documentation hasn't been made in a couple of days, but, with strong recommendations on how to write an help page and a blank check from the rest of the community, a dedicated wikiproject has been working on it since two to three years. That allows us to point newbies to an help page explained by the editor they use (in most cases VE). My point is that it is possible to maintain such pages and I don't think it depends of the size of the wiki.
Concerning documentation, edited and maintained by the WMF and translated by volunteers pages exist: Visual editing, Notifications types, Recent Changes, etc.
Hope this helps.
Trizek - I would never contend that it's impossible for a local community to successfully maintain a wide range of documentation to help with editing. I simply believe that it's very unlikely. If you could point to dozens and dozens of examples where communities do in fact devote plentiful resources to this, I'd be happy to change my conclusion.
And I'm aware of the VisualEditor user guide, since I helped improve large portions of that. But WMF has made no commitment to maintaining core user documentation, part of which would be to define what "core" is, and part of which would be to have a specialized group responsible for that - including, for example, the paying of translators.
That's your opinion. With one example, I see things as possible. If you need "dozens and dozens" of examples I'm afraid I can't do anything to convince you. :) My point is also that a situation can be different because of a given cultural apprehension of change, or how a community decides on everything. There is no miracle, just motivation.
Same thing concerning documentation and translation: motivation is everything. I believe more in a taskforce of specialized volunteers, recognized for their skills, than a group of paid editors.
Hi @John Broughton. I think you've raised a really important issue. Our notion of how to do this is that we will model the Help lessons, formats and styles our research proves are most effective. After that, we will need extensive community support to make sure the new help "lessons" reflect local policies and tech, which varies wiki to wiki considerably. So, on day 1, the new system will be an up-to-date and improved help facility. But how long will that last? Will the community continue to keep the modules up to date?
This problem is perhaps worse for the system we have in mind, since most of it will only ever be seen by newbies. After all, if you happen to see a Help page that is out of date, you have the ability to fix it—or at least report it as needing to be fixed. But you will probably never see any of these modules; the only people who will are the ones who have no idea how to remedy any problems they encounter.
I should note that we're not, for the most part, planning to focus this system on a whole lot of individual tools, as you suggest. At least for the first release. A large part of the impetus for this came from the New Editor Experiences research. In particular, this system addresses finding #8, which showed that "new editors’ greatest challenges are not technical but conceptual," in that they don’t understand wiki policies, including the “pillars” of Wikipedia like notability, neutrality and verifiability. Such policies, of course, change more slowly than tooling does. Still....
I wonder if we might address the problem of getting out of date by including a "Was this helpful" link with the modules? A user who clicks it would get a form inviting them to describe their problem. I don't know who would get the output of that form, but presumably there would be a page and maybe a group interested in helping newbies?
I think that John has a good point, and it's something that we should consider in the project design. It will be important to figure out who's responsible for updating the help messages long-term. If there's a situation where a change would need to be made in software rather than messages -- a different trigger, pointing to a different spot on the page -- then there needs to be an ongoing commitment from a product team to keep those updated. If it's just updating the words, then editors can do that -- but we'll want to talk to the community on the wikis that are using the feature, to make sure that there's a group of people who are willing to monitor and update in the future.
Regarding finding #8, that the greatest challenges are conceptual, that's why I mentioned "(c) enabling those administrators to add links within the [help] text, so those more inclined could go to help and/or guideline pages." For example, when adding a citation, the help/information pop-up could include [for the en.wikipedia.org system] the text "Be sure that the citation you're adding is from a reliable source", with "reliable source" being a link to https://en.wikipedia.org/wiki/Wikipedia:Identifying_reliable_sources . That guideline page is well-maintained by the English Wikipedia community, so there isn't a lot of reason to worry about that, and it has links to relevant Wikipedia policies, so it's a good place to start for those who want to understand conceptual issues.
Have best practices based on design research and usability will be in any case vital.
Based on my experience, there is a lot of pages that are considered as "good" while they are not easy to read or understand for newcomers.
This onboarding project is a very promising initiative. I've felt for a long time that new users should be told the basics at the very outset and not just be left to sink or swim, very often leading to frustration for themselves and others.
What I would very much like this process to cover is how to use user space - the main user page and user subpages. There are plenty of new users who seem to think this is just like Facebook: once you've put your CV, self-publicity or advert on your user page, you've done it and that's your total involvement with Wikipedia. Or, the slightly more sophisticated ones create an unreferenced promotion page in their user sandbox, roughly formatted like an article; apply search engine indexing as VE makes it so easy to do; job done. Please include in the onboarding process guidance about what the user page is for and what it's not for; what to do when you've created a user draft and how to get it on the road to being accepted as an article; and intervene if they apply indexing in user space, which is almost never a valid action for a new user.
Concerning user (sub) pages, a way to avoid self promotion published there being visible outside of Wikipedia would be to NOINDEX all those pages by default. It has already be done by some wikis.
Sure @Trizek (WMF), it's already no-indexed *by default* in en-wiki. The trouble is that VE makes it super-easy for anyone, even the newest editor, to reverse this setting, and they do it a lot. A point I made nearly a year ago , section "Page options in Visual Editor", but didn't get anywhere.
Reading replies you get there, that sounds similar to what can happen on any Wikipedia: anyone who wants to have an article will do whatever is possible to get it, even publishing it on odd places. Have a clear guidance as you suggest may help to avoid article creations on user page or sandboxes.
Thanks so much for your suggestion @Noyster. We are definitely looking at the idea of introducing the user talk page, but had not really gotten much into the idea of the other pages in the user space. I will add this to our list of topics to consult on. It sounds like you have some experience in this area. Are you a patroller, new user helper, just an observant user? Thanks again.
Thank you for your interest JMatazzoni. There is no doubt that many new users have no clear concept of the distinctions between their user page, user sandbox or draft pages, and Wikipedia articles and it will be real progress if we can help them with this. The patrolling part of my activities on enwiki brings me into contact with many newly registered editors and I try to welcome them and offer guidance, or when necessary deter them from doing what they're doing.
I use the User page in training as the first thing people edit. You can always spot people who trained with me as early versions of their user page will look like
https://en.wikipedia.org/wiki/User:Deecee2000
where we do italics, bold, headings, wikilinks and citations, as well as addressing any potential conflicts of interest. I figure that's 99% of what they need to know to get started. If I don't have the luxury of much time, I just teach citations. That's the one "must have". Other people can copyedit and wikify what you wrote but they cannot guess what your source was.
There seems a mismatch between the "in context" ambition and what seems like a "Series of lessons that experienced Wikipedians would demand very new WIkipedian know before they are let loose". Nobody is going to do Modules 1-500 if they just want to fix a spelling. I'd be more inclined to ask each new user (based on some minimum number of edits) first "What do you want to do", offering the likely options like "fix spelling, grammar, punctuation", "change something that is wrong", "add some new information", "start a new article about me, my business, my product", "start a new article not about me, my business, or my product", as you want to teach them different things. Obviously there are more things they might want to do. Then tell them the *minimum* they need to know to do that task (just-in-time learning).
The change/add need to know about citations for their new information. I wouldn't give them the full range of citation-providing formats. E.g. in the VE, I'd just give them a text box where they can paste URLs or type whatever and emit it wrapped in ref tags and let someone else sort it out.
Those wanting to write articles about themselves should be sent packing, I doubt that this type of person is likely to become a regular contributor (too self-motivated), so let's get rid of them quickly before they waste everyone's time at AfC.
Those wanting to write articles not about themselves etc (no CoI) should firmly be told "not now, it is too soon, you need at least 100 edits to existing articles to gain experience" (this is what I say in F2F training and I am very upfront that the unlikelihood of a new users successfully creating a new article - I am an occasional reviewer at AfC and I know what it's like). AfC involves the user making a lot of effort and seeing it never published; not a useful way to onboard someone so just STOP them from doing it. AfC is a stupid solution to the problem. Once they've met the magic 100 (or however many) edits, when you ask what they want to do, offer "start a new article" for the first time and talk about notability and how to demonstrate it. Move to a *lightweight* AfC process where initially they fill in a form answering "title", "what is about", "what is it important/interesting for Wikipedia", and 2 independent citations (stop them investing a lot of effort on article writing until they have the green light on notability) - including some examples of "good" and "bad" ways to answer these questions in terms of demonstrating notability.
While we have watchlists for articles being edited, we don't have watchlists for "new user doing edit". I have a topic interest (Queensland). If any new user turns up editing on that content, I am happy to reach out and offer to help (having some canned ways to do this helps a lot - I use Twinkle > welcome > project-specific WikiProject Australia as my standard welcome). If there was a way I could sign up to be notified of the activity of new users within my topic space, that would be a good thing (for this purpose, topic space could be defined either by a category closure or a WikiProject template). At the moment, they have to edit something on my watchlist for me to notice them.
My own experience of supporting both F2F and remote new users is that email is infinitely preferred to Talk or Teahouse. Firstly they understand how to send an email, they don't understand how to write on Talk or Teahouse (assumes you know about source editing! - why no VE on Talk, User Talk or Teahouse). I put a VEFriendly template on my User Talk page so they can use it if they want to do so with VE, but really they like email. Also email is private (their ignorance is not public knowledge and they can be honest about what happened if it involves another user) and they can email screenshots, which you cannot easily do on-wiki). While we know that there is a an "email this user" on left side-bar of a user page, it's rarely found by a new user (and of course some users don't have a registered email address on their Wikipedia account). I hand out business cards at F2F training with my email address and I publish my email address via whatever medium is being used by remote training. Because I edit with my real name, I actually get a lot of new users where I have written something on their User Talk page (or sometimes a potential new user who has found my name in the history of an article or an article talk page) tracks me down in real life (fairly easy to do as I have a website on which I have both my real name and my email address) and then emails me or phones me or manages to contact me via a friend of a friend from Linked-In. It shows how hard our Talk mechanism is that new people find it easier to reach me by such other means! I think when we ask the new user "what do you want to do today", I think contacting someone they have encountered or someone connected to an article of interest to them should be an option (might require a bit of detective work on their user page, or recent edits on any articles they are interested in).
As part and parcel of this, we must very strongly encourage the provision of an email address when signing up, and keep suggesting it while they are a new user, as it is the best way to talk with them.
The other thing I think we should do is divert any new user from making a change to a high quality article or high readership or one with many page watchers. These are very high risk places for new users to start. Instead just put their request onto the Talk page and hope someone follows up with them. Only allow them to do early edits on lower-risk articles, low importance, stub/start/C quality, low readership, low page watchers. This is the approach I take in F2F training, I start them working on their own User page to learn the minimal skills (bold/italic/heading/link/cite) and then provide "low-risk" real articles and one or more sources for each of them to update the article. I was a mentor in the OCLC course for around 300 public librarians last year and I saw that many of the new users went for "high risk" topics for their first edit and were reverted. I don't know if anyone has the revert stats based on the risk factors I mention, but I would be very surprised if revert rates aren't higher on the articles I identify as high-risk. I know when I edit outside my normal topic area, I experience more reverts, not because I don't know standard Wikipedia rules but because I don't know what that topic area regards as a reliable source, or what conventions/agreements have been established at a particular WikiProject, or even how that sub-community interpret the same standard rules.
"The other thing I think we should do is divert any new user from making a change to a high quality article or high readership or one with many page watchers"
I can understand your reasoning, but consider how this would impact things like 1Lib1Ref, or an editor who just adds photos (possibly their own, taken especially) to articles that lack them.
Hi @Kerry Raymond. Thanks for all this great input. It's fantastic to hear from someone with your experience. I'll respond to a few of your points below.
"I'd be more inclined to ask each new user...first 'What do you want to do'"
- Agree. I'm adding a form element along these lines to our concept for the Welcome sequence. I’ll post an updated version tomorrow.
“Those wanting to write articles...should firmly be told ‘not now, it is too soon, you need at least 100 edits to existing articles to gain experience’”
- We've been puzzling over what to do with newbies who want to write articles. It’s one of the most common reasons why people register, according to research. We’re thinking along the lines of directing newbies to Article Wizard, which we’d want to revise and expand. I’m not sure about telling people they can’t write an article—especially since different wikis have different standards/priorities on this question (some really need new content). But perhaps it would be a good idea to include a dose of warning/encouragement to start with something easier.
“Those wanting to write articles about themselves should be sent packing.”
- How many options we might practically put on the “what do you want to do today?” form mentioned above—i.e., how detailed to make it and how many separate paths it can direct users to—is an interesting question. We know that most articles by non-autoconfirmed users get deleted. It sounds like you’re suggesting that COI is one of the most common reasons (I’ve asked for research on this, but it might take a while). In your experience, is that true? What are the other big ones? Notability...what else?
"When we ask the new user 'what do you want to do today', I think contacting someone they have encountered or someone connected to an article of interest to them should be an option
- Agree. And I'll return a question. There is research suggesting that new users who manage to connect with the community have a greater chance of success. Which would suggest we should make a point of emphasizing the importance of talk pages across multiple "lessons". Does that check with your experience?
"I wouldn't give them the full range of citation-providing formats."
- Yes, I think in general we're realizing that VE should be the focus (except for talk pages). Thanks.
“My own experience...is that email is infinitely preferred.”
- Sounds right. I’m adding a prompt to the Welcome sequence asking for email and explaining why providing an address will help us help the user.
"The other thing I think we should do is divert any new user from making a change to a high quality article or high readership or one with many page watchers."
- Thanks for this suggestion. I assume your warning about high-risk pages would also apply to pages tagged as a Controversial topic, Recent deaths or under various types of restrictions as well? We’d planned to use such edits as a trigger for a lesson on Neutral POV. It sounds like a warning that such edits have a high probability of being reverted is something we might also usefully add?
Re: newbies and new articles. I know newbies often want to write new articles. It's why I deliberately tell them the chances of succeeding as a new contributor are very low. Walk before you can run etc. Generally as an AfC reviewer, you can suspect (and not usually prove) CoI and undisclosed paid editing, so the bulk of new articles from new users are declined for failing to demonstrate notability (but I know I generally set the bar higher on notabilty when I suspect CoI). That's why above I suggest that AfC should start with a light-weight process focussed on just getting over the notability hurdle. Move to a *lightweight* AfC process where initially they fill in a form answering "title", "what is about" (only let them have a small number of chars to do it in) "what is it important/interesting for Wikipedia" (again force it to be short), and 2 independent citations (stop them investing a lot of effort on article writing until they have the green light on notability) - including some examples of "good" and "bad" ways to answer these questions in terms of demonstrating notability. Don't let anyone invest time and effort into writing the body of an article until they have passed the notability hurdle.
If we actually enforced that you couldn't start a new article until you have 100 (or some other number) of edits, would people get started and do edits to existing articles in order to qualify or would they walk away? Would we deter people who would become long-term contributors or would we only deter people there to "(ab)use" Wikipedia without intention of giving back in any way? Or would we just get 100 rubbish edits? Obviously it's difficult to answer such questions. And we do have to be mindful of not "burning" the time and goodwill of our existing contributors with onboarding the newbies. AfC does seem to burn its reviewers (they are always calling for more, I respond, do it for a while, then drop out again -- it's just so soul-destroying). I'd rather thank/welcome new users I spot on my watchlist doing little edits and try to nurture them.
Re: connecting new users with existing communities or individuals. I do believe welcoming/thanking new users helps and I know this because some of them tell me so, here's few recent ones
https://en.wikipedia.org/wiki/User_talk:Kerry_Raymond#Teneriffe,_Queensland
https://en.wikipedia.org/wiki/User_talk:Kerry_Raymond#Sisters_of_St._Joseph_of_the_Sacred_Heart
https://en.wikipedia.org/wiki/User_talk:Kerry_Raymond#You're_welcome
https://en.wikipedia.org/wiki/User_talk:Kerry_Raymond#Thanks
https://en.wikipedia.org/wiki/User_talk:Kerry_Raymond#A_Kitten_For_You!
But of course there are the ones that figured out how to get to my User Talk page and I know newbies have difficulty doing this, so I hope there are more out there with "warm fuzzies" even if they could not thank me for them. The last one (A Kitten For You) actually illustrates the value of showing people their impact. What they are referring to is
https://en.wikipedia.org/wiki/User_talk:Rose64bit
where I explain that 1000 readers have now had the benefit of reading an article improved by their edit. I get similar reactions from our 1Lib1Ref folks when they look at the Articles Viewed on our 1Lib1Ref2018 dashboard:
and you see the staggering multiplier effect for edits on very ordinary articles that are about 2 months old now. Why not put that statistic on everyone's contribution page? Obviously we all know that people benefit from our edits, but I confess that those Articles Viewed statistics on the dashboards blew me away when I first saw them. OK, I know it's not a perfect metric. If I do an edit that gets reverted, it would still count for the Article Viewed statistic which would steadily grow over time. But as a way to show a good-faith newcomer that they are doing something that matters, it's a powerful tool even if the actual value is a bit rubbery.
Re: avoiding high risk articles. Yes, I see nothing wrong with saying to a new user that the article they want to change is "very important", "widely read", or "controversial" or whatever other risk factors are perceived. I think our mistake is not being honest with our new users. The encyclopedia "anyone can edit" is only half true. Anyone can try but many will fail. Again, I make these points face-to-face and people seem to accept the wisdom of them. "Often the wording in such an article has been debated at some length by several people, so if you just jump in and rewrite those words, they aren't going to be very happy with you". And I also caution against deleting anything as a newbie. "Remember someone else wrote that and they think it is interesting/useful, if you delete it without a very good reason, then you are probably not making a friend but an enemy, it's better to focus on adding new information not deleting what's already there". Everything I say is about de-risking the newbie experience, I want them to survive long enough to be "bitten by the bug" of contributing so they can survive the negativity that they will sooner or later encounter. "Learn to pick your battles", "Let that one go", "If you encounter pushback in one article, forget about that topic and work on another article, it's a big encyclopedia, remember". These are my regular pearls of wisdom both to the newbies and to myself -- I get bitten like everyone else and I do point that out too to the newbies! I don't want to create the expectation that there is a point at which everyone will become nice to you. I try to reinforce that there are more nice people on Wikipedia than nasty ones, it's just that we tend to remember the nasty ones more, and that there are a lot of readers for whom we are doing something wonderful. "Every good edit is a gift that keeps on giving".
(Test message for https://phabricator.wikimedia.org/T190429)
I notice that the project description was editor-agnostic but as someone who does face-to-face training, teaching the source editor is a disaster (nobody could understand/remember what all the symbols meant and very few people continued to contribute after the trianing session). For the past few years, I have taught the Visual Editor and people find it very easy by comparison. How I taught them didn't really change, just the editor changed. Younger people often manage to figure out the VE for themselves quite quickly. Older people need a little more hand-holding but still manage to become proficient (I mostly get older people to my training sessions, they are less likely to be confident enough to just jump in and edit on their own). So I would strongly encourage the on-boarding to be based on the VE.
I definitely +1 your analysis of VE being the best to train new people, @Kerry Raymond! I use it on my workshops and I do workshops for experienced users so that they can use it as well! :D
However, I understand why editors are not mentioned: wikitext is an editor and will not be removed, and not everyone has access to VE. So the two editors need to be in in-context help contents.
Those in-context contents will be triggered by actions done, and people will get tips based on how they edit and which tool they use. If someone finds a way to edit that uses a different editor (for instance in an help page only covering wikitext), that person will be happy to have in-context help specific to wikitext. Same thing if a person changes something on their behavior and now gets access to VE.
I'm just concerned by conservative people who may ask to have wikitext first and before VE, because that The Only True Way To Edit™. That's the purpose of that windows that pops-up when you first edit, saying that there is a wikitext editor. The only thing that people get with that is confusion. Privilege an editor is IMO not realistic, not desirable and will definitely not serve the projects' goals.
We have been talking about the decline in editors and the gender gap and all the other contributor gaps for years now, but nothing changes. If we think that VE is the best way to successfully bring new people on board, then we have to enable it everywhere. The conservative assumption of en.WP is that nothing needs to change about anything policy or process-wise and, unsurprisingly, if nothing changes, we should be unsurprised that we get the same outcomes we always have. The framing of the gender gap question has been for several years "how do we fix the women to make them fit into Wikipedia?", but why do we never frame the conversation as "how we do fix Wikipedia so that women want to contribute?". That's the conversation I want to hear, the one that accepts that our culture has its problems and must be changed. The VE is just one part of that conversation.
And, indeed Trizek, I see from your user page, you have been asking this very question for several years.
At present we aren't planning to included many "lessons" about the different editors. I will post an updated lesson list tomorrow, but the only places where we've planned to talk about editors are:
- A super-basic intro that says here's the Edit button and here's the Publish button; just insert to start writing.
- A note about switching between editors. This would only come up if the user clicks on the pencil icon.
- Some minimal Wikitext in the context of teaching how to write a talk page message (how to indent, how to sign).
I think our assumption is that we will guide users into VE, and that it is enough like a word processor that they will be able to figure out most basic writing and editing tools. There is pretty thorough and recent VE Help, after all, in case users have questions.
Remember, this system is not designed to replace Help pages, but to get newbies up and running and over their first batch of hurdles. Do you think more on the topic of VE is needed than what I've noted?
There are no older topics