Talk:How to contribute
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| RTL - how to flip the floats? | 2 | 13:22, 14 January 2014 |
| Starter kit | 0 | 21:32, 10 January 2014 |
| Translationcusytayausuysggdgyay | 1 | 00:02, 15 November 2013 |
| Icons | 20 | 02:12, 6 September 2013 |
| Mobile view | 4 | 20:11, 5 September 2013 |
| Request - Allowing Marathi language translation for this page (mr) | 3 | 13:59, 26 August 2013 |
| Removal of video | 1 | 22:17, 19 August 2013 |
| Missing pieces | 7 | 21:21, 21 March 2013 |
| Space | 6 | 13:34, 20 March 2013 |
| Redesign | 4 | 13:25, 20 March 2013 |
| Special:MyLanguage and anchored links | 10 | 20:36, 13 February 2013 |
| Scope of translation | 7 | 16:01, 24 January 2013 |
| Landing pages are not equal | 2 | 06:18, 2 January 2013 |
| Making this page the landing page for any new contributors | 2 | 03:14, 1 January 2013 |
| "New opportunities" template | 1 | 03:13, 1 January 2013 |
| Cluttered page | 1 | 23:19, 28 December 2012 |
| All those pages with tasks for (new) contributors | 2 | 22:55, 27 December 2012 |
| Bug triage | 0 | 18:56, 24 December 2012 |
I just want to say that I saw this and I agree we should fix it but I don't know how to fix it because I have no experience dealing with RTL/LTR compatibility. Maybe Aaharoni can shed some light?
I looked through (all?) the CSS rules, and couldn't find one that I could use for this. It can be easily done with a css rule that utilizes the class .mw-content-rtl to flip the directionality. I could also do this with a template, but then it won't be automatic. Indeed, maybe Amir will have an idea.
Thanks to the help of a few real new contributors, Starter_kit is basically ready to be an important page for newcomers. I'm thinking in linking it from the "Get involved" main box, but before I want to check with the followers of the page whether you think that page is useful and ready. Please discuss at Talk:Starter kit. Thank you.
Icons have been uploaded and listed at Project:Visual identity with the activity they represent and the credits. There are a few other icons to find or discuss, but let's do it at Project talk:Visual identity.
Yes, nitpicking as usual: note that not all those icons are PD, so |link= is not good practice. Some in the Noun project even explicitly require attribution by name.
If you find better versions that are PD please propose them here. Nemo, point taken and I will remove the |link=.
I Propose:
- File:Tools-hammer.svg for "Testing"
- File:Tango-style question icon.svg for "Support"
I believe visual consistency is more important than Public Domain license vs CC. Wikimedia Foundation Design/Agora Icon Set goes for simple black icons and I don't see a reason not to follow that trend.
See media:How to hack on Wikipedia.pdf for other icons proposed.
Proposals for missing icons:
Development: http://thenounproject.com/noun/source-code/#icon-No1171 Support: http://thenounproject.com/noun/first-aid/#icon-No2208
Still searching for Documentation.
Proposal for Documentation: http://thenounproject.com/noun/book/#icon-No7656
As you have seen, I have changed the icons for API and Translation. I will wait an extra day for Development, Support and Documentation just in case.
Note: I posted a similar comment at Thread:Project talk:Calendar/About consistent icons/reply. I'm copying it below:
- I hope that we'll come to a point where we have a set of reusable, consistent and recognizable icons across mediums (wiki pages, blog posts, slides, etc.).
- Don't forget to add the proper credits in your slides where required. It's easy to do in a presentation, but it's a bit trickier to show credits on wiki pages, because when we use them as icons, we usually use the
link=parameter to hijack the image's link (that would otherwise have led to the image credits). For events and the calendar, I've found a good enough workaround (credits are listed on Template:Event/doc and linked to from Template:Event header), but we'll need to make sure we show or link to proper credits wherever we use those icons.
- Perhaps we should start listing the icons somewhere (other than the template's doc) to have a central place both to define our visual language, and also to list proper credits. Maybe Project:Visual identity?
The current mobile view isn't great. Discussion about it here: <http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071526.html>.
I'm not a div expert. Is the content of the current table supposed to be in a div containing others like this?
<div (table)>
<div (row)>
<div (left content)>Web API</div>
<div (right content)>The content of all Wikimedia projects...</div>
</div>
<div (another row)>
...
</div>
The page is now using Template:Contribution, which basically implements the div structure you're describing, I think. The code still doesn't collapse well, though.
MZ thanks for doing this. I just made some tweaks and it's looking a lot better on mobile now :D
It looks great on mobile now. Also thank you for the nanotutorial on how to go from wikitable to divs. :)
It is requested to open/allow this page for marathi(mr) translation please,if it is not a policy to withhold this page for translation. Thanks.
You translated it fully (thank you), so I guess this is resolved.
There is some problem in the language bar. In the first stroke, when one opens the page, Marathi(mr) language does not appear. we have to try twice or thrice. then it appears. maybe some problem with my comp. or what. anyway,Thanks.
Yes, on WMF wikis it may take up to a week or two; it's normal. Redirects with Special:MyLanguage always work.
Hi. I've removed the video (File:How to hack on Wikipedia.webm) from this page for now as I think it's problematic. In my experience, developers have short attention spans. They've come to this page to hopefully find a way to contribute ("How to contribute"). The first minute of this video is spent polling the audience. The second minute is spent explaining Wikipedia and MediaWiki and Wikimedia, using the wrong MediaWiki logo, over-emphasizing Wikipedia, and confusingly showing Wikia and other non-Wikimedia projects in relation to MediaWiki and its sister projects.
I'm not sure what's in the rest of the video as I got bored and stopped watching. This is part of the issue with this video. A video about "How to hack on Wikipedia" should explain how to hack on Wikipedia. Quickly. Efficiently. Logically. Perhaps we can link to the slideshow presentation used in the video or something similar? The video as-is is doing more harm than good.
It's still unclear whether this page will serve for Bug 33464 – Add "Developer" or "API" link to footer of Wikimedia wikis
I had a list somewhere (an outline, really, I think) of what should be included in this type of page. For example, the XML database dumps available at http://dumps.wikimedia.org. There are likely other things missing. It'd be good to figure out what those things are sooner rather than later as they may impact the layout.
Though this raises a broader question about this page's goal: is it to draw in people to MediaWiki development or is it to encourage re-use of content from Wikimedia wikis? Or is it some combination? The exact purpose of this page is still a little unclear to me.
Wikimedia data dumps fall in the category of reuse/remix. Instead of creating a new section I would rename the API one to integrate both API and offline. "Reuse"? "Data"?
The exact purpose of this page is the same than Get involved, isn't it? We want to attract technical profiles of all kinds and we want to redirect each profile to their best next destination.
Is there a page summarizing the different ways to reuse Wikimedia data? The more I think about your suggestion of pointing to the various ways to reuse / remix the more I like it. If such page doesn't exist we could create it. It would contain an overview to the API, the dumps, the offline projects, InstantCommons... Anything else?
I don't know of such a page. I'd intended for Get involved to be that page, but I'm perfectly happy working on a more specific page like Re-using Wikimedia's data (or m:Re-using Wikimedia's data).
Pieces you're missing could be: Squid cache, HTML dumps, the Toolserver, and Wikimedia Labs.
I don't think HTML dumps will ever be produced again. The WMF hosts ZIM dumps produced by others and probably thinks this is enough, there are no plans for more HTML dumps. It's ok to include them in a generic "dumps" or to add them again when they're updated, but currently it's a waste of people's time. I don't know if mentioning ZIM dumps would be ok either, as they exist only for a subset of wikis.
A page about reusing Wikimedia data would be useful. If you ask me, I would prefer to have it in this wiki.
Is there anything we can say to contributors about Squid? In fact I had to remove the whole Sysadmins block after realising that, at this point, we have little to no docs explaining how someone can get involved and do a useful contribution.
Dealing with (parsing) wikitext is almost impossible, but the XML dumps at dumps.wikimedia.org are wikitext-only. So if you need HTML instead of wikitext, you have three options:
- HTML dumps (but there haven't been new dumps in years inexplicably);
- scrape the live site (the HTML Squid cache layer); or
- use the API's action=parse (often quite slow for a single page, even worse for millions of requests).
I think we should be clearer about how to do option "2". For example, by specifying an appropriately useful User-Agent and by not slamming the site with too many requests in too a short a period of time (this is how bots and spiders get blocked). And discuss iframing, hot-linking, etc. This quickly gets more into Meta-Wiki territory, though.
Looks like what you need may be now at m:Research:Data.
Dropping a link here: http://browsersize.googlelabs.com/
The URL should be https://m.mediawiki.org/wiki/How_to_contribute (mobile view) but I'm not sure the interpretation in that site corresponds to what you actually see in mobile devices...
https://commons.wikimedia.org/wiki/File:How_to_Contribute_-Mobile_1.png
https://commons.wikimedia.org/wiki/File:How_to_Contribute_-Mobile_2.png
https://commons.wikimedia.org/wiki/File:How_to_Contribute_-Mobile_3.png
Screenshots from my phone.
The layout is too wide for my screen, the header especially.
That site won't reflect it, but now the mobile view is more decent - without significant changes in the desktop view. The list of topics could welcome some mobile love but it's late and I got tired of fighting the combinations between CSS + HTML tables + wikitext tables + MobileFrontend.
While I was adding Product development to the page, I felt the need to reorganize the contents, and I ended up completely reorganizing the layout and simplifying the content. I feel the page is now easier to read and to navigate.
I believe I've explained all the changes in the edit summaries, but I'm available to discuss my changes if some are controversial.
Mmm ok. Yes, it is an improvement. I like it because it's closer to be mobile friendly, although it is not yet. Having one column instead of 2 things will be easier to fix.
We need to pay more attention to the sorting of areas though. In the previous layout I tried to keep an order of relevance starting with API. Now we have Product development and Design at the top, which are precisely two areas where we are not really ready to get contributors and make them happy.
Right; "Readiness to get contributors" wasn't a criterion in the reordering; Instead, I focused on the kinda chronological order in which stuff usually happens (i.e. we start with Product Development, then Design, then Development, etc.).
If you think that that criterion comes first, feel free to reorder. If the order is the only major thing that bothers you, I'm happy :)
If links with anchor makes through "Special:MyLanguage", such as Special:MyLanguage/Communication#Landing, requires that anchor was unchangeable in all languages. I've added fixed anchor in the Communication/ru, but this should be considered when migration to new translating system.
You're right. Usually, when the target page is translatable, we place some additional untranslatable anchors for the purpose of linking. We should probably migrate Communication to Translate, do you volunteer for the migration? ;)
Nice! Reading the tutorial should probably be enough; when you have some free time, if you prepare the page for translation I can then mark ("approve") it and then you can import the old translations where possible. (For the following times a bureaucrat should definitely give you translation admin flag.) Let me know,
Please check my chsnges.
Current issues:
- link to template
{{MediaWiki Introduction}}(how to mark subpage as optional element ?) - link to template
{{Irc}}(keeping as is) - how to make a localized categories? (I recently saw somewhere a template for this, but I can not find now)
- need remove old language section at the bottom (saved until the migration)
- how to import the old translations in semi-automatic mode?
Whoops, already approved. :-)
- That's the correct way, translator can leave "en" if template doesn't exist in that language (better to document at /qqq for that unit). Template:Translatable navigation template attempts some magic.
- Ok.
- There's a template on translatewiki: and one on wm2012:, I don't remember here.
- Removed now.
- There's no way I'm afraid, for individual pages... Maybe we could figure out some semi-automated way to mark and import pages with a pattern (I proposed configuration pages). Now it's some manual work. I'm also unsure if the links to identi.ca etc. have something translatable; if translations didn't alter names, they can be removed from translation and made static I guess.
Edit: note that FuzzyBot is supposed to pass and update the subpages (i.e. override with the English version until translation are re-added) but there's currently some problem with the job queue so it didn't yet; translation works, though.
Hi. I was pondering translating the page to French (with my volunteer hat), but I'm wondering if it makes sense to translate this page if all the pages it points to remain in English. Is the goal only to translate this page, or is there some more ambitious plan to translate a whole set of pages to encourage participation to development, testing, design, support etc. in multiple languages?
I've tried to point out what of the listed activities or pages are English only: it shouldn't be all of them...
The availability of further pages and tasks in languages other than English will depend on the push of the own speakers of those languages. There is nothing planned in advanced.
I think it's worth translating this page because it links directly from the homepage and it aims to be a landing page for all kinds of users, especially if we indeed get that link in the Wikipedias' footer. It's also short and now I consider the existing texts quite stable.
I'm not sure about the need to specify "(English only)" in the English version. It feels weird and redundant. Is this something we can leave for the translations in other languages, where such detail does make sense?
Also a couple of questions:
- Can you have a look to the i18n code? I fear I broke something with the introduction of the wiki table.
- Does the multilingual nav bar need to be at the top? Can it be placed at the bottom?
The languages bar at the bottom feels useless, and it doesn't harm anything at the top, while showing that we do support more languages. I'll check the tags later today.
The "English only" is meant to show that – even if most of the pages including this are only in English – one actually can contribute in other languages too, in the areas where English is not specified as a requirement; I'm not sure what those areas are, but where in doubt that may be something to fix.
Development, Design and Testing are the few areas I see where being able to communicate in English is really needed.
Most areas are likely to benefit from a localized page imho:
- Translation: obviously;
- Support: to provide support in multiple languages;
- Documentation, API and Sysadmin: to provide documentation in multiple languages.
So I'd be in favor of using Translate on those pages as well, and use Special:Mylanguage links on this page.
As for the (English ony) disclaimer, I do think it's valuable for translated versions of this page, but I understand Quim's point about being redundant on the English version. How about we use the qqq message for these strings to tell translators to add the disclaimer, even if it's not in the source text? It's not a perfect solution but it seems like a good compromise.
(As for the language navigation bar, I agree it's fine at the top.)
Ok to the bar at the top, then.
If you are in a page in English and you just to another page / tool in English only and no hints of translations, it is safe to assume that most users will correctly deduce that it's only only. The "English only" note in translations make sense because it warns users that whatever is behind the link will be in English, and not the language they are currently reading.
The list of areas open for L10n proposed by guillom makes total sense.
- - Can you have a look to the i18n code? I fear I broke something with the introduction of the wiki table.
I fixed it. Previous translations have been invalidated because the page has changed a lot, but I've tried to make translations as easy and straightforward as possible by keeping the wikitext of translatable chunks clean. Let me know if you encounter other issues.
Looking at the current version of this page, the landing pages are not all equal. For example, compare Localisation and Design. Does this make sense?
Not all linked pages are "landing pages", is this what you mean? For instance Localisation is not linked anywhere if I remember correctly, only a section of it is. In general, different links on this page have different audiences, so it makes sense for them to be different.
This page is currently linked from Main in plenty of languages, but actually almost no secondary page links to it when it comes to point new contributors. Maybe this is good, maybe not. I will start looking at competing / complementary pages just to check if we can improve our intake of new contributors, bringing them to their preferred destinations.
For instance,
- I just added a link pointing here from the Get Involved block at Wikimedia Engineering.
- And another one at How to become a MediaWiki hacker.
- Get involved is a potential competitor of this page. I just recommended at its related proposal to use this page instead.
Ideas welcome! Also other ideas to improve this page.
I agree that Get involved should be merged to this page, although this might involve some reorganisation of the content to fit different audiences (if a different audience for that proposal is chosen).
I'm fine with redirecting Get involved, as long as we can adequately cover the goal of helping people re-use content from Wikimedia wikis somewhere (here or on Meta-Wiki). I posted about this page's purpose above, as it remains unclear to me.
Template:New_opportunities is outdated. Only editors with special permissions seem to be able to update it. I'm for removing it until we find out a way to keep that block updated with relevant information. Actually it's a tough task... See the other thread #All those pages with tasks for (new) contributors.
Template:New opportunities was semi-protected. I just removed all page protection from it for now.
Yes, this page is now a lot more cluttered than it used to be. However, I wanted to make sure we have all the relevant pages identified, put in context and linked. Before it would take a lot of experience for a newcomer to find those pages (a paradox). Now we are closer to this goal.
There next step is to work on one and only one landing page for each section. Then we can move many of the details to a visible "How to contribute" section in each of those pages" leaving here the very basic introduction for each section, a link to a main page and perhaps just an extra link to a popular / catchy destination within that topic.
There is still one section missing: Promotion. But before we need to have a landing page for that. This will be my next task, related to Groups/Proposals/Promotion.
And there is one section we could get rid of: Donate. The link is good, but it can simply go in the first paragraph of the page, that I still want to polish a bit. Imagine a sentence like
You can edit, you can donate, and you can also contribute your technical skills in many ways.
I just discovered Project:Tasks... There is also Annoying little bugs and Annoying large bugs and Mentorship programs/Possible projects. Shouldn't we harmonize all this? Keeping these lists alive takes a lot of effort.
One idea would be to split them into categories (development, documentation, design...), connect each category to the respective hub / landing page and then use transclusion if we want to show these open tasks in other pages.
Should "Help sort bugzilla reports" link some of the pages in Bug_management#For_Triagers_.2F_Bugsquad_Community?