@ericschurter got informed by @fjsanpedro that the initial work for docs research is done. We now have to wait for further instructions/needs! So that's good!
Roman Kubachanged the descriptionCompare with previous version
@ericschurter@rkuba I read through all the issues on the devopscreate boards yesterday and tried to identify everything I thought would need my attention with the Technical Writing label. Here's what I see for %13.11, split by type of work:
If we assume (conservatively) that each issue causes 3 points of work (more than a sentence, less than a paragraph) I'm looking at 24 points for me for ~"group::editor" and 174 points for all my devopscreate groups. Those numbers don't include release post items (almost always 3-pointers) and any surprise work that wasn't anticipated in release planning.
Fuzz factor alert: when I used this system in my previous team, @cnorris started glaring at me when my weekly point total went above 50-60. The catch: I'm still not 100% convinced that the work at GitLab correlates 100% with my work at $previousJob, so I don't know if 50-60/week is the right number for me, in this stage, at GitLab. If it is, though, the current slate of work is a minimum of 43/week, with much of it stacked at the tail end of the release, as engineers finish up their milestone work. We also don't know the number of release post items that will come in a couple of weeks. (An additional unknown: I'm unsure how many points / week that devopsgrowth will send my way; they were significantly higher than anticipated in %13.10.)
With unknown scope on these issues, and an unknown number of release post items, I can't 100% predict my milestone, but I think it's safe to say to @cnorris ahead of today's 1:1 -
I will need assistance with devopsgrowth, especially in the latter half of %13.11, to fulfill my commitments to devopscreate.
As expected, I better front-load any and all non-feature work in the first two weeks of the milestone or I'm likely to have a bad time in the last two.
This is our current focus. We had a pairing session yesterday and we figured out the best way of setting up the content editor in the Wiki form. Today, we will focus on understanding how we can save a new format.
This issue will be closed because it does not accurately reflect the problem. When repository is turned off, CI is not available anyway, so using a CI token is irrelevant. While investigating this issue, we found two separate, but related problems. When the repository is disabled, neither a deploy key, or a deploy token, can be used to perform Git operations on wikis. I will create two separate issues for correctly authorizing deploy keys and tokens in this case.
Creating this prototype is underway. I am using tiptap in a codesandbox environment to set up the testing scenarios. Should be ready to go out sometime next week for participants for feedback
Other things
Updating some mockups for discussion about how other elements like Analytics could look like in the left nav gitlab#326703
In maintainer review. This is the first step to start updating the new sidebar structure. Also merged gitlab!57619 (merged) and gitlab!57812 (merged) within this scope.
Looks like this has been de-prioritized by infrastructure due to their capacity 😞. I have an idea how we might be able to handle this a bit Dev-Ops-y. @ericschurter@rkuba, we should probably set aside a meeting to discuss this.
I've got a POC MR which addresses this and pays off some significant technical debt. I need to polish this and split it up then it should be good to go 🎉
Summary
I've had quite a few things on my plate this last week so I'm feeling a bit behind. I've got the 🔴 up and am working on knocking things off my backlog 😅
Other things
I've got my last Moorehouse lecture today and had one pop up unexpectedly last week
This gl-tabs MR has been a lot more to it than originally anticipated by everyone involved. I'm particularly interested in this because it will fix a Web IDE bug.
Sourcegraph has been buggy on MR diffs, which has persisted after an attempt to fix it. I've addressed this holistically (and added some integration tests!) which is a nice win (see MR) 🎉
Like Paul, I haven't had much time to work on this. But based on the spike so far, the Model-View-ViewController client-based approach seems appropriate for this (because it's less coupled to the Rails view layer than other navs). We did get a little work done to pull out the necessary EE-specific parts to separate EE mixin classes and clean up some linting errors.
Almost done with review. This is an important refactoring I worked with Lukas and Alex on to move all the spam-related communication to headers. It's a prerequisite to make it much easier to add CAPTCHA to other areas of the app. Once this is merged, then we can turn on the snippets spam feature flag and finally wrap up gitlab#217722 (closed)
I still have a few DB performance related issues I'm trying to wrap up or get off my list. Most of these seem not actionable, and need larger architectural changes, but the exact process for how that will work is still being worked out
Created a prototype for this validation session in Vue using codesandbox (example). Started analysis and currently working on this.
Other things
Will be working on a solution validation plan that will be looking at a bunch of possible interaction patterns. One way to make this work approachable is to request collaboration from other designers who have an interest in nav work as well. gitlab#326703https://gitlab.com/gitlab-org/ux-research/-/issues/1384
I’ve submitted all the MRs to deliver Commonmark support in the editor. gitlab!58678 (merged) decouples Markdown serialization/deserialization from the editor itself and allows customizing the rendering process in the editor’s client. gitlab!58791 (merged) implements Commonmark support. I didn’t have to write a lot of code for that which I really appreciate 😄
Other things
Thanks everyone in the team for the great discussion in gitlab#325203 (closed) to define the best path to introduce the Content Editor MVC in the Wiki.
Next release I'll be more proactive about identifying these things before they are actually due, then we can collaborate async to make sure I'm not missing anything.
Thanks for the head's up @pslaughter and no worries there. In general, we'd verify something hits production before adding it to the release post but it's always good to know going in whether there's a likelihood of missing the milestone.
There's some discussions that need to happen about different architectures arising to implement a data-driven approach for navs, and agreement on a ubiquitous domain language for this work. Currently only Paul/Chad/Eric have discussed. More to come...
Currently blocked by another ongoing refactor of the IssuableBaseService hierarchy constructors, which is big, but fairly straightforward and low-risk, and hopefully close to being ready for review. Also, good news is I had a meeting with @mushakov and @serenafang regarding the eventual handoff of the ongoing CAPTCHA work. @serenafang kindly agreed to start looking into gitlab#327360 (closed) !
various DB performance issues
🍊
Same as last week. I still have a few DB performance related issues I'm trying to wrap up or get off my list. Most of these seem not actionable, and need larger architectural changes, but the exact process for how that will work is still being worked out