Thu, Mar 8
Created and sent out invites. Also decided to call this a "retrospective" vs "post mortem" :-)
Tue, Mar 6
Mon, Feb 26
Moved to blocked as I am waiting for response from Daniel on my request.
Feb 21 2018
Feb 20 2018
First pass of stewardship reviews in progress. Will be meeting with Victoria and Toby to plot a course of action for the first four.
Jan 19 2018
Jan 11 2018
Sent off email to @daniel before the holidays with some observations and questions regarding the review queue process as it stands today and areas that we could improve it. I think the question is two-fold: What review should we do prior to deploying something into production for the first time vs what should we do on an ongoing basis when something is in production.
Jan 5 2018
Would this by chance be an approach to storing other CI data longer terms as well (i.e., test results)?
Jan 4 2018
@Catrope, yes I think this is related.
Dec 26 2017
Reached out to Daniel for more info. Also reached out to Marko regarding the review process for services.
Dec 13 2017
Dec 12 2017
Dec 11 2017
Nov 24 2017
Yeah, that's a good point. One of the thoughts that I've been having is to recognize "stewardship" outside of the foundation and sister orgs. Meaning, anyone can agree to be a steward provided they are willing and capable of being a steward as defined (whatever that ends up looking like).
Nov 14 2017
Got it. Thanks!
Nov 13 2017
Nov 10 2017
@greg Created a page with program management information. See: https://www.mediawiki.org/wiki/Technical_Debt_Program/Program_Management
Changes to Developers/Maintainers page where reverted as they referred to an "in draft" page regarding stewardship, which I totally understand.
Updates have been made the the developers/maintainers page, but there are still gaps. Part of the challenge is that some are hesitant to claim "stewardship" without knowing what that will entail. Working on the definition in parallel.
Final edits made (missed some later comments :-)). Requested final review to be done.
@Dzahn thanks for creating this. I didn't see an email come through with a password. Can you resend?
Nov 3 2017
I like the concept of SourceRank and think something like that would be good for extensions. I think we'd want to add some additional code health attributes though. But I do like the inclusion of things like documentation. Perhaps another Rank attribute is whether or not the extension has a steward.
Oct 31 2017
Added first pass changes regarding code stewardship.
Oct 24 2017
Oct 23 2017
@Aklapper at this point the scope is what's listed at https://www.mediawiki.org/wiki/Developers/Maintainers. However this is the time to expand (or contract) as necessary.
Due to have it up for review 20171023.
Oct 5 2017
Have received a fair bit of feedback/recommendations on some of the orphaned components. Will be updating the Developers/Maintainers page with those that are straight forward, and seeking additional clarification on those that aren't.
Sorry Mel, should have looked at this task prior to asking you about the status.
Sep 26 2017
Held both initially scheduled video-based SIG sessions. Notes available. Will look to setup an IRC based session too.
Sep 12 2017
Per our chat. I'd like to get some more info from you if possible. We could do it async or in a quick meeting if you'd prefer.
Sep 7 2017
Sep 6 2017
Sep 1 2017
Postmortem meeting etherpad notes available at: https://etherpad.wikimedia.org/p/20170831-Post_Mortem-T164173.
Aug 24 2017
Thanks @Volker_E, I've noticed other examples where parent tasks are the tasks actually describing the technical debt aspect of the change and the subtasks are just work elements towards that goal. I think the description that you've provided is a good example of technical-debt - Going from a distributed approach to setting those values to a central approach. Reduces potential errors and makes life better for developers :-)
Thanks for explaining. As something that helps development, I think its a good candidate for overall code health. I do like your definition.
Aug 23 2017
Hello, not clear why this is marked as Tech-Debt. I know I'm missing some context, but I am looking to better understand our current working definition of Technical-Debt. thx
Cool. Makes sense. Thanks for the clarification.
In "Dead", do you mean no longer used, or broken. If the prior, than yes minor TD, probably should be removed. If the later, then it's just a bug.
Not clear to me why this is Technical Debt. If I understand this task correctly, it's abandoning/deprecating colors used in the UI. From what I can tell from the code changes, there was no refactoring done, just a change in color.
Not clear why this is tech-debt.
Is this task considered TD because it's essentially duplicate code (reading into the "mostly copy-paste" comment)?
Not clear why this is considered technical-debt. I understand the desire for the change as described, but I wouldn't generally consider it TD. For more information on our evolving TD definition, please see: https://www.mediawiki.org/wiki/Technical_debt
This appears to be more of a general development practice/pattern request. Probably could address this concern (and possibly already is) as part of coding standards. We can then decide if refactoring to meet those standards is warranted through various ares of the codebase.
@daniel: Just a heads up that I will be sending out a request to have post-mortem participants refer to the incident report for background/context in preparation for the meeting. My plan is to send out the reminder August 25th 1:00 UTC. If you could have your input added by then, that would be helpful.
Aug 17 2017
@zeljkofilipin, I'd like to create various "series" of tech talks, for example there will be a "Code Health" series, and perhaps, a "QA Series". Should we have this one be the first in a "Automated Testing Series" or something of that nature?