This tend to diverge away from the chrome and into the content, which
is a lot more difficult to change. (Urgh, way to long…)

Anyway, I have this really-really weird idea that “staff” should
provide (extremely good) design elements, and then local projects
would chose to use them in favor of their own because they are better
than what the have locally. Those elements should typically provide
some features that would otherwise be to difficult or expensive to
make locally, thus the projects would want to use them.

Example 1: The staff could provide a complete set of design symbols
for featured articles, not the jammed together mix that is used now.
At some projects they even claim that the current kludges are what WMF
want to use, and that they are “Wikipedia”. Pretty weird.

It should be pretty easy to set up a project “Design elements:
featured articles”. We probably need them to have sufficient details
for badges, indicators, and pages. They should have symbolic names,
and they should probably adapt to the chosen skin. Remember, if the
design element is an SVG then it might be styled.

Remember to add a page indicator from the item on the local page
itself. Now we only add badges in the sidebar.

Added feature: The design elements will look good over all projects
and skins, and they will look consistent. (Increased conformance over
projects leads to decreased boundaries between the projects, that is
less “us and them”.)

Example 2: The staff could provide necessary modules for common tasks
like an infobox, navbox, taxbox, succession box, etc. There are not
many of them. Most of them will use structures at Wikidata, with some
local adaptation.

The present use of modules tries to support existing templates, but I
believe that is a wrong approach. By doing this we perpetuate present
problems with the templates. Instead of redirecting calls to modules
through templates we should simply call the modules as
{{module:infobox}} in the articles, and only add arguments as
necessary to solve problems. The module should check out the type of
item (P21) and act accordingly. (Yes it is possible, but then modules
must implement and use a __tostring metamethod. It is a tech-ting.)

Added feature: I guess editors will be glad to finally have infoboxes
that work as expected in all articles, and the conflicts between
various infoboxes would go away . (The soccer fans will probably hate
it, they can't style the infobox in the colors of their favorite
soccer team. Don't tell them they can still mess with the colors
through template styles.)

Example 3: The staff could provide well-defined help pages, that could
be localized at Meta, and the localized page transcluded into the
local project. It should be possible to link to such pages as if they
were local, and even if locally overridden they should always exist.

It is a pretty large undertaking to define all necessary help pages to
kick off a local project. To have some help pages, even in English or
some other language, would be a real boon. Also to link those pages we
need a slightly more advanced help indicator. Now we only have one
link that follows the page, but there are probably several given the
role and state of the user.

Added feature: It would be possible to find the help pages, thus
making the editing simpler. (Some oldtimers will probably get a grudge
over their favorite nit-pick items being thrown out on the common
pages, and will thus insist on keeping their favorite help page.)

On Sat, Dec 14, 2019 at 9:38 AM Amir E. Aharoni
<amir.ahar...@mail.huji.ac.il> wrote:
>
> Yes, and that's why I really, really, really want to hear more feedback on
> it from various communities of editors, including criticism. That's also
> why in my proposal I write that it's a requirement that communities must be
> able to override any central functionality, and I only speak about the
> generic principle of making templates global, mentioning particular
> templates only as examples. I leave everything else to the communities.
>
> The parts about which I wrote that they will have to be done mostly by
> staff are the parts that require heavy PHP coding, code review, and
> testing, and as far as I know, most of the people who know the relevant
> areas of code well are on staff. (I might be wrong. Also, everything I'm 
> saying
> here are my own assessments, and they don't represent the WMF in any way.)
>
> However, the more volunteer developers and editors participate in it, the
> better—not because it saves money, but because it makes the project more
> "owned" by the community.
>
>
> בתאריך שבת, 14 בדצמ׳ 2019, 09:12, מאת John Erling Blad ‏<jeb...@gmail.com>:
>
> > I get a little scared when I read “probably, but not necessarily,
> > mostly by staff” because all kind of central standardization creates a
> > whole lot of arguing in the individual subprojects. If that
> > standardization means changing a whole lot of templates I'm afraid it
> > will create much more fighting than real solutions. I'm a little
> > “Marvin” here…
> >
> > On Fri, Dec 13, 2019 at 10:14 AM Amir E. Aharoni
> > <amir.ahar...@mail.huji.ac.il> wrote:
> > >
> > > ‫בתאריך יום ה׳, 12 בדצמ׳ 2019 ב-23:37 מאת ‪Pine W‬‏ <‪
> > wiki.p...@gmail.com
> > > ‬‏>:‬
> > >
> > > > I'm thinking out loud here. Are there any estimates of would be
> > required in
> > > > terms of time (both staff time and community time) and money to make
> > > > templates and other tools be much easier to globalize across wikis and
> > > > across skins? I'm looking for an answer that is more specific than "a
> > lot",
> > > > but isn't a promise or a detailed estimate.
> > > >
> > >
> > > Difficult to say.
> > >
> > > I won't make an actual time estimation, because I'm very bad at doing it,
> > > and because I have too many conflicts of interest ;)
> > >
> > > However, I do hope to give you something more specific than "a lot". I
> > > envision the following feasible plan for "global modules and templates,
> > > phase 1":
> > > * Make a localization framework for modules. (
> > > https://phabricator.wikimedia.org/T238417 ; probably, but not
> > necessarily,
> > > mostly by staff)
> > > * Develop a documentation page and a framework for making robust modules
> > (
> > > https://phabricator.wikimedia.org/T238532 ; probably, but not
> > necessarily,
> > > mostly by staff).
> > > * Make modules storable and loadable from a global repository, and
> > > *actually enable it on all Wikimedia projects* (
> > > https://phabricator.wikimedia.org/T41610 ; probably, but not
> > necessarily,
> > > mostly by staff).
> > > * Migrate most local modules from all the wikis to using global modules,
> > > and deleting all the migrated local modules. This will have to be done by
> > > the editors communities in many wikis, and it will only be feasible if
> > all
> > > the points above are planned and executed well. The challenges I expect
> > at
> > > this step are:
> > > ** Making sure that just the right amount of things are global and
> > > everything that communities want to override locally can be conveniently
> > > overridden.
> > > ** Making tough choices about which modules to use when several
> > communities
> > > developed modules with similar functionality. For example: English,
> > French,
> > > Russian, Spanish, and Hebrew Wikipedias have modules for loading Wikidata
> > > values. They aren't the same, but they probably should be. Merging them
> > > into a global module will require a lot of good-faith collaboration.
> > >
> > > Note that I only mentioned modules. Templates have some extra challenges.
> > > But once modules are done well, a "phase 2" of this project, that would
> > > tackle templates, will become possible. Also, global gadgets will have to
> > > be a separate project. Maybe the same localization framework can be used
> > > for both modules and gadgets, but I cannot think of anything else that
> > they
> > > really have in common.
> > >
> > > All of the above is my interpretation of discussions in the recent Tech
> > > Conf in Atlanta (other people may have a significantly different
> > > interpretation). See these Phab tasks, and the web of other tasks linked
> > to
> > > them:
> > > https://phabricator.wikimedia.org/T234661
> > > https://phabricator.wikimedia.org/T52329
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > https://meta.wikimedia.org/wiki/Wikimedia-l
> > > New messages to: Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > https://meta.wikimedia.org/wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to