Continued maintenance is a problem that we have with a lot of things in the
world of Wikimedia software 🤷♂️
Some features can be developed in two months and used for years without
needing much more maintenance. The current setup of the Community Tech team
is ideal for this.
Some need two months of development and then years of maintenance, begging
the question whether it was a good idea to plan the development for only
two months.
Some need a year of development and continued maintenance after that.
That's tough, but sometimes it's justified, and that's just how it is.
The examples I gave are not usual features, but at least partly significant
changes in infrastructure. Infrastructure of all kinds needs maintenance.
Understanding the difference between product and infrastructure and the
interplay between them has on occasion been a challenge for us, too.
בתאריך יום א׳, 13 באוק׳ 2019, 22:53, מאת Brian Wolff <bawolff(a)gmail.com>om>:
One concern id have if this approach is scaled up, is
what happens to
maintenance of these projects after they are done? Not that this isnt a
problem with traditional teams too, but with the wishlist approach it seems
like it would be all the more problematic, especially for larger projects.
--
Brian
On Sunday, October 13, 2019, Amir E. Aharoni <amir.aharoni(a)mail.huji.ac.il
wrote:
> I don't know if restricting the wishlist only for other projects is so
> terrible. Non-Wikipedia projects have complained for years that they are
> not getting enough attention, so perhaps giving them extra love at the
> expense of Wikipedia makes sense.
> I would look at a wider problem,
though. Over the years that the
community
wishlist vote has been working, a lot of
excellent projects were
completed
> by the Community Tech team: global preferences, the pageviews tool,
> TemplateWizard, wiki syntax highlighting, edit summary improvements, and
> many more. However, several projects that received a very large number of
> votes were declined, not because they were undesirable but because they
> were too big for this team, which by its nature is oriented at small,
> timeboxed projects. That, by itself, is understandable.
> The real trouble is that even though
there is demand for these things
> (given the vote results), and even though no-one seems to think that the
> ideas are invalid or undesirable, they ended up not being done. Some
> notable examples:
> * Cross-wiki watchlist (#4 in 2015, declined:
>
https://en.wikipedia.org/wiki/Wikipedia_talk:Global,_cross-
> wiki,_integrated_or_stacked_watchlists#Declined
> )
> * Global gadgets (#1 in 2016; I couldn't find the reason for declining)
> * Global templates (#3 in 2015; marked as "in development by Parsing
team",
> but not actually done)
> All of these things are still very
much in demand. All of them happen to
be
particularly beneficial also to non-Wikipedia
projects, but if they will
be
> proposed for this year's wishlist vote and get a lot of votes, will they
> again be declined because they are too big for the Community Tech team or
> will they be escalated to another team (or teams) that can execute them?
> If there is no commitment to such
escalation from higher management,
we'll
stay stuck in a ridiculous situation in which the
most needed projects
are
> also those that cannot be carried out.
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
>
http://aharoni.wordpress.com
> “We're living in pieces,
> I want to live in peace.” – T. Moore
> בתאריך שבת, 5 באוק׳ 2019 ב-2:44 מאת Yuri Astrakhan <
> yuriastrakhan@gmail.com>:
> > Ilana, restricting wishlist to
non-Wikipedia this year is a very sad
> news.
>
> > For many years, wishlist
survey was the best way for the community to
> talk
> > back to the foundation, and to try to influence its direction. WMF
mostly
> ignored these wishes, yet it was still a
place to express, discuss,
> aggregate and vote on what community needed. Big thank-you is due to
the
> > tiny community tech team that tackled the top 10 items, but that's just
> ~3%
> > of the foundation's employees.
>
> > WMF has been steadily
separating itself from the community and loosing
> > credibility as a guiding force. Take a look at the last election --
> almost
> > every candidate has said "no" to the question if WMF is capable of
> > deciding/delivering on the direction [1]. In **every** single
> conversation
> > I had with the community members, people expressed doubts with the
> movement
> > strategy project, in some cases even treating it as a joke.
>
> > This is a huge problem, and
restricting wishlist kills the last
effective
> feedback mechanism community had. Now WMF
is fully in control of
itself,
> > with nearly no checks & balances from the people who created it.
>
> > I still believe that if WMF
makes it a priority to align most of its
> > quarterly/yearly goals with the community wishlist (not just top 10
> > positions), we could return to the effective community-governance.
> > Otherwise WMF is risking to mirror Red Cross Haiti story [2] --
hundreds
> of
> > millions of $$ donated, and very few buildings actually built.
>
> > With great respect to all
the people who made Wikis what they are
today,
> > --[[User:Yurik]]
>
> > [1]
>
> >
https://meta.wikimedia.org/wiki/Affiliate-selected_Board_
> seats/2019/Questions#Do_you_believe_the_Wikimedia_
> Foundation_in_its_present_form_is_the_right_vehicle_for_
> the_delivery_of_the_strategic_direction?_If_so_why,_and_if_
> not,_what_might_replace_it
> > ?
>
> > [2]
>
> >
https://en.wikipedia.org/wiki/American_Red_Cross#Disaster_
> preparedness_and_response
>
> > On Fri, Oct 4, 2019 at 5:18
PM Ilana Fried <ifried(a)wikimedia.org>
wrote:
>
> > > Hello, everyone!
> >
> > > My name is Ilana,
and I'm the product manager for the Community Tech
> > team.
> > > We’re excited to share an update on the Community Tech 2020 Wishlist
> > Survey
> > > <https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2020>.
This
> > will
> > be our fifth annual Community Wishlist Survey, and for this year,
we’ve
> > decided to take a different approach.
In the past, we've invited
people
> to
> > write proposals for any features or fixes that they'd like to see,
and
the
Community Tech team has addressed the top ten
wishes with the most
support
> votes. This year, we're just going to focus on the *non-Wikipedia
content
> > projects* (i.e. Wikibooks, Wiktionary, Wikiquote, Commons,
Wikisource,
>
Wikiversity, Wikispecies, Wikidata, Wikivoyage, and Wikinews), and
we're
> only going to address the top five wishes
from this survey. This is a
big
> > departure from the typical process. In the following year (2021),
we’ll
> > > probably return to the traditional structure.
> >
> > > So, why this
change? We’ve been following the same format for years —
> > and,
> > > generally, it has lots of benefits. We build great tools, provide
> useful
> > > improvements, and have an impact on diverse communities. However, the
> > > nature of the format tends to prioritize the largest project
> (Wikipedia).
> > > This makes it harder to serve smaller projects, and many of their
> wishes
> > > never make it onto the wishlist. As a community-focused team, we want
> to
> > > support *all* projects. Thus, for 2020, we want to shine a light on
> > > non-Wikipedia projects.
> >
> > > Furthermore,
we’ll be accepting five wishes. Over the years, we’ve
> taken
> > on
> > > larger wishes (like Global Preferences
> > > <https://meta.wikimedia.org/wiki/Community_Tech/Global_preferences>
or
> > Who
> > > Wrote That
> > > <https://meta.wikimedia.org/wiki/Community_Tech/Who_Wrote_That_tool
>),
> > > which are awesome projects. At the same time, they tend to be lengthy
> > > endeavors, requiring extra time for research and development. When we
> > > looked at the 2019 wishlist, there were still many unresolved wishes.
> > > Meanwhile, we wanted to make room for the new 2020 wishes. For this
> > reason,
> > > we’ve decided to take on a shortened list, so we can address as many
> > wishes
> > > (new and remaining 2019 wishes
> > > <https://meta.wikimedia.org/wiki/Community_Wishlist_
> Survey_2019/Results
> > >)
> > > as possible.
> >
> > > Overall, we look
forward to this year’s survey. We worked with lots
of
> > folks (engineering, product management,
and others) to think about
how
we
> could support underserved projects, all
while preserving the dynamic
and
> open nature of the wishlist. *Please let us
know your thoughts
> <https://meta.wikimedia.org/wiki/Talk:Community_Wishlist_Survey_2020
*
> > related
> > to this change. In addition, we’ll begin thinking about the
guidelines
for
> this new process, so *we want your feedback
> <https://meta.wikimedia.org/wiki/Talk:Community_Wishlist_Survey_2020
*
> (on
> > what sorts of processes/rules we may want to consider). Thank you,
and
> > > we’re very curious to see the wishes in November!
> >
> >
> > > Thanks,
> >
> > > Ilana Fried
> >
> > > Product Manager,
Community Tech
> > > <https://meta.wikimedia.org/wiki/Community_Tech>
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l(a)lists.wikimedia.org
> > >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l