Thu, Jan 11
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.
Fri, Jan 5
Would this by chance be an approach to storing other CI data longer terms as well (i.e., test results)?
Thu, Jan 4
@Catrope, yes I think this is related.
Tue, Dec 26
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?
Aug 16 2017
Aug 14 2017
Aug 11 2017
One item that was discussed during the Vienna Hack-a-thon was having some form of rating system that would be available for extensions. This rating would be perhaps based on some objective measures (derived from some the criteria mentioned in this session) as well as some subjective developer ratings. Looking to do something like this for Code Health generally speaking.
Aug 9 2017
This is an interesting topic. During the hack-a-thon I did a session on "building better software" and one of the topics discussed was along these lines. We had some 3rd party users/developers of MediaWiki that wanted to see if there was a way to "rate" extensions based on certain criteria like your describing. Very interested in the outcome of this session (not there in person unfortunately).
Jul 31 2017
Jul 27 2017
@zeljkofilipin Rachel is still setting them up for us, by I offered to get them going and coordinating some topics. When do you want to do it?
Jul 21 2017
Technical Debt and Code Health are definitely related. However, Code Health is a superset of Technical Debt. It covers the broader topic of how software was written and it's influence on readability, maintainability, stability, and simplicity. It's about helping the developers be more productive while increasing "developer happiness" and overall software quality.
I'm hesitant to have Code Health discussions in the qa@ list due to the potential limitation in subscriber-ship/interest. It's my belief that Code Health discussions are intended for(if not sourced from) developers, engineering managers, in addition to those in more traditional QA roles. If we want to avoid the creation of another list, I'd propose that we use a broader engineering list. That being said, I'd still like to start with a separate list if possible.
Jul 19 2017
After further investigation, it appears that this isn't an output issue from Jenkins. I was receiving mail list digests and the "scrubbed html" content attached to it doesn't get automatically rendered by the browser and instead just loads the HTML source. Testing the html file outside of the digest seems to work fine and the html is properly rendered.