[Wikitech-l] Re: Unsubscribe from mail list

[Zoran Dori]

Hello,
I'm sorry because you want to leave, but you need to send an email to
wikitech-l-le...@lists.wikimedia.org

Best regards,
Zoran

пон, 21. јун 2021. у 20:37 Arpit Maheshwari <
arpit.maheshwari08041...@gmail.com> је написао/ла:

> This is a request to please kindly unsubscribe me from your mailing list
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Unsubscribe from mail list

[Arpit Maheshwari]

This is a request to please kindly unsubscribe me from your mailing list
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Production Excellence #32: May 2021

[Kosta Harlan]

Thanks as always for this report, Timo.

One reason the count is higher in May is because that's when the Growth
team began implementing a chores process
 (credit to Readers Web
for the inspiration ) to
systematically review and log production errors that appear on our team
dashboard

in Logstash. (We've also implemented a triage process for our inbox
, which used to have
~2000 tasks and is now at 10.) Some of the tasks we've filed from Logstash
are probably duplicates or close relatives of existing production error
tasks, but because we are trying to timebox our triage process, we don't
always succeed in ensuring that we identify existing tasks before filing
new ones.

A bigger problem is how to handle our growing pile of tasks that need some
attention; as a team that's tasked with feature development, making time to
work on maintenance tasks unrelated to the code we touch day-to-day is a
challenge. So, while we are going to be more diligent about filing tasks
when we see issues in Logstash, unless something appears to be badly
broken, it is probably going to stay as an open task.

Kosta

On Mon, Jun 21, 2021 at 4:55 AM Krinkle  wrote:

> How’d we do in our strive for operational excellence last month? Read on
> to find out!
>
> Read on Phabricator at
> https://phabricator.wikimedia.org/phame/post/view/236/
> Incidents
>
> Zero incidents recorded in the past month. Yay! That's only five months
> after November 2020, the last month without documented incidents (Incident
> stats ).
>
> Remember to review Preventive measures
>  in Phabricator,
> which are action items filed after an incident.
>
> ---
> Trends
>
> In May, we unfortunately saw a repeat of the worrying pattern we saw in
> April
> ,
> but with higher numbers. We found 54 new errors. This is the most new
> errors in a single month, since the Excellence monthly began three years
> ago in 2018. About half of these (29 of 54) remain unresolved as of
> writing, two weeks into the following month.
>
> Figure 1, Figure 2: Unresolved error reports stacked by month.
> 
>
> Month-over-month plots based on spreadsheet data
> 
> .
>
> ---
> New errors in May
>
> Below is a snapshot of just the 54 new issues
>  found
> last month, listed by their code steward
> .
>
> Be mindful that the reporting of errors is not itself a negative point
> per-se. I think it should be celebrated when teams have good telemetry,
> detect their issues early, and address them within their development cycle.
> It might be more worrisome when teams lack telemetry or time to find such
> issues, or can't keep up with the pace at which issues are found.
> Anti Harassment Tools None.
> Community Tech None.
> Editing Team +2, -1 Cite (T283755
> ); OOUI (T282176
> ).
> Growth Team +17, -4 Add-Link (T281960
> ); GrowthExperiments (T281525
>  T281703
>  T283546
>  T283638
>  T283924
> ); Echo (T282446
> ); Recent-changes (T282047
>  T282726
> ); StructuredDiscussions (
> T281521  T281523
>  T281782
>  T281784
>  T282069
>  T282146
>  T282599
>  T282605
> ).
> Language Team +1 Translate extension (T283828
> ).
> Parsing Team +1 Parsoid (T281932
> ).
> Reading Web None.
> Structured Data None.
> Product Infra Team +1 WikimediaEvents (T282580
> ).
> Analytics None.
> Performance Team None.

[Wikitech-l] Re: Mailman 3 - is there an API available?

[Amir Sarabadani]

There have been requests to build something similar (for example automated
tools for checking only users with certain rights would have access to the
internal mailing list of that right) and the good thing it's now much
easier to do in mailman3. I hope to get around to doing it soon. I make
sure to keep your use case in mind and at least make it slightly easier for
you. Stay tuned.

Best


On Sat, Jun 19, 2021 at 9:33 PM Martin Urbanec 
wrote:

> Hello Kunal,
>
> Thanks for your answer. WMCZ has a private self-hosted wiki that can be
> used as a data source for the maillist.
>
> Unfortunately, who is a member is private information, so I'm not sure how
> it would be possible to sync it with WMF service. An alternative would be
> to somehow (privately) expose the subscribers in a machine-readable form,
> so I could create a bot to indicate subscribeness status in a wiki table,
> but I'm also not sure how feasible that would be.
>
> Martin
>
> so 19. 6. 2021 v 18:20 odesílatel Kunal Mehta  napsal:
>
>> Hi,
>>
>> On 6/19/21 5:32 AM, Martin Urbanec wrote:
>> > does Mailman 3 (as-installed by Wikimedia) have an API I could use?
>>
>> Yes it has an API, but it's not available for public access. Everything
>> in Mailman3 is driven by a REST API, however that API has a single
>> user/password and has access to do *everything*, so we can't hand it out.
>>
>> > I'm an administrator of WMCZ's internal maillist, and it would help me
>> > if I could sync the addresses with evidence of members with a script
>> > rather than having to do it manually each time a new member is admitted
>> > (or quits).
>>
>> So...depending on what you plan on syncing it with, this could be
>> doable. In  it's been
>> requested to auto-subscribe people to the Cloud-announce list, which
>> might require making some part of the REST API accessible in the
>> internal network or having scripts run on the lists server.
>>
>> If you could file a task explaining a bit more detail where you want to
>> sync from, how often it needs to sync, etc. then we could probably
>> figure something out.
>>
>> -- Kunal
>> ___
>> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
>>
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/



-- 
Amir (he/him)
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/