Jenkins Documentation Office Hours, 27 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Docs SIG 2020 03 27

Description

Jenkins documentation special interest group discussed plugin labeling, adoption, and deprecation. We deferred discussions of the documentation roadmap and Google Season of Docs to the Jenkins documentation e-mail list

A

Hi everyone: this is the Jenkins documentation special interest group. It's the 27th of March 2020, thanks very much for joining us. Let's go ahead and look at the agenda and then we'll work through the contents of the agenda.

A

So first first item will report on previous action items. Then we'll talk about plug-in labeling principles and guidelines, then the plug-in adoption and deprecation processes then documentation roadmap and those are the toe and then google season of Doc's 2020. Are there other topics that should be added to the agenda house.

B

A

Great okay, then, let's go ahead and first is the action items. I apologize, I'm still not I still haven't submitted my project ideas in a pull request. I think what will happen there is we're going to use the road map as a place to hold some of those, at least as an initial capture, and then we'll put more ideas as they gather. I've got six summary I continue to post those to post the videos to Twitter and I'll. Do a blog post here in the next week or two on the ways that Doc's have evolved.

A

Oleg, you and I have talked about a palm and bomb developer meetup for the for for use of bill of materials in maven. Any sense is, is that stabilizing now, or should we continue to hold this on the do of the future? Nothing.

B

That we need to do that. I'm about is including photos zero. It's on my list before the next week or the week after and after it happens, we can definitely sit in so they meet up for that great okay. Waiting for that everybody's welcome to join and talk about the anything else related development. So we had three or four minutes all today and we got some audience today, I'm interested in these topics, because it's not only about Jenkins but those about the usage of software development tools, even even develop Jenkins buttons.

B

You can study something from that like.

A

So, thank you. Then. The last item was on listing the github apps and the plugins they use them. I. Don't remember, I, don't have recall the details on this. One should I just delete this item so.

B

It came from the request to clarify which applications can be used by clicking developers and the current situation that a common beginner cannot access the released Authority approved applications, so we need to somehow document it probably in the github. Is it again.

A

Okay, so this is so I as a plug-in developer. Don't know that release drafter is available to me or that over, let's see where some others some of the Probot tools, the thing that does depend bot, for instance, and if I don't know their move they're available, I need to see a list somewhere. Okay,.

B

And so it's something on the back burner for me. I do eventually do it, but you think you know other action items on my side. I wouldn't expect it soon right unless that is something to have it and.

A

I haven't seen it seems strong need to have it, so that seems very reasonable.

B

A

So next topic plugin labeling guidelines, labeling principles, so the story here is that previously Jenkins plugins were categorized by by labels that were stored at one point on the wiki and after the wiki was no longer particular helpful. Let's see a know like if I've got the right location. The labels are right over here and I can use those two to find all the plugins that match a particular label and storing them in the wiki. The wiki is now read-only, so that won't work anymore.

A

Github has a concept of topics, and so plugins can be have topics controlled by the plug-in maintainer which which are the can be used as labels to help people find things better on the on the plug-in site. So one of the one of the discussions was hey are we do? We have the right techniques for labeling, plugins and so I had sent out a proposal here which suggested a discard which suggested some ideas for oh that's impossible to read ideas for guidelines.

A

We might use in labeling things, because Oleg and I had a discussion about hey.

A

What are the appropriate labels to use and not use on a on a particular plugin, so the principles I was proposing were: let's try the label for users, and by default we would only label from with white listed labels the labels that are chosen in advance and skipped. This one was I, think a controversial one skipped labels provided by parents and then then the other controversial one was. Labels should be relevant to at least five plugins before they are added to the whitelist Oleg. You and I had conversations about this.

A

This is probably a good time for me to ask you to chime in what are some issues you'd seen some problems or things you think we need to address here in the discussion. That's.

B

All in this discussion, basically.

A

B

I agree how we label things, because there are two approaches. My concern about this proposal was not specifically to the least but the suggestions and the law regarding principles so, for example, how to label plug-ins for get happen, etc, because the approach Marcus told label everything which might be useful to ingot hot news on my approach was to label plugins, which are specifically related to github and yeah. That is a conceptual difference in how the labels would be displayed right now how how labels were organized before you.

B

Actually you the focusing technologies, and so, for example, all plugins providing some functionality kubernetes would be marked with kubernetes label one of the ones we added recently to highlight such feature. There is but yeah. My approach basically follows the one which existed before and the dynamic mark that you proposed a different approach right.

A

Very good point, so a key difference there was should so in in your in your in the indie. The way it's been in the past is not even particularly yours right. It's that how we've applied it in the past, a plugin that was specifically focused on github would be labeled github, whereas this this example basic build branch, build strategies would not be labeled. Github github did I understand correctly. Yes, that's right.

A

So this may be a place where, where others are certainly welcome to chime in I'm, okay with either I think it would be perfectly fine to say, hey we're not where we're going to say it needs to be specific to that technology.

A

In in the specific benefit, labeling technique, Oh, like do you envision how they would find basic branch build strategies? Would they find it by some other means.

B

Because there are still additional labels like SEM, which could be used, then later you could add some analytics because we have usage stats. For example, we could provide information like people who install a github bench such plug-in usually install these basic variable strategies, something like that. So how other marketplaces like Amazon operate?.

A

Okay, so the there we would use the use. The data after the initial labeling use the data that that can be gathered from the association of plugins in an installation. I'm not I'm, not sure, I'm, clear on where we get that data yep.

B

Association or maybe just documentation, references or whatever but yeah. For me, it's how it would be done practically because otherwise you have explosion of configurations. For example, everybody uses pipeline, not everybody but yeah 70% of Jenkins users. So would your mark pipeline plug-in Swiss, github Bible, because yeah, if you use github, you would definitely benefit from pipeline, so we approach causes a lot of pitfalls like that, and I would prefer to be careful about that unless that is strong recommendation where the boundaries a good point.

A

So we have a, we have a pool of 1518 1000, almost 2,000, plugins and you're right that if, if the this, this tends to be a broader proposal, then- and it would thus tend to generate many many hits on on the word pipeline or the word.

A

If the example you give pilot pipeline label is assigned to every plugin that provides anything any extension to pipeline, then, when I search for pipeline I will probably get almost every plugin in the system, I'll get hundreds and hundreds of them, and that's that's not particularly valuable to me good, okay, so.

B

Yeah, that's what's my point about that then yeah, my preference would be to proceed. It is how Jenkins operated before and it would be also more convenient for making ours, because we expect plug-in maintains to manage to github topics. Yeah I use my github for cutting permissions to set topics where a few it's reasonable, but in general it's up to plug-in main games. So if you set up a complicated policy, it won't.

A

B

A

And- and maybe is it, would it even be simpler than to say hey we're not going to worry about a policy, particularly, we will allow it to grow entirely organically, and thus it would follow the pattern that we've used in the past or do you do feel stronger than hey a stated policy will help even if they've stated pay, even if the stated policy is specifically to continue as we did before, I will.

B

Spend too much time on that, we definitely need some kind of summer in plug-in, developer and plug-in maintainer documentation. Because, right now we don't document that one can use it hot topics on the de communication. It's not a big deal, because many, a popular plugins do use labels, so people will discover that they can make some effect, and now it's also visible in the Jenkins and because the same labels are consumed from updates entered by Jenkins installations.

B

But still some kind of documentation would be nice, for example around in host accession sections. So when you submit a flag in, you can also set up label secession, but I wouldn't expect to have a strict protests or jape for that, because, basically, a set of guidelines, good.

A

Okay and I think I think I've understood more clearly. Now your your rationale and I'm fine with that how about if we put the action item on me or are there others in the meeting that would like to comment? Give insights on hey I would like this or that and.

B

Have Daniel on the call I'm doing almost once a lot of time on my agenda, speaking manager, I.

C

Sorry I had to accept delivery. Just know.

C

Where exactly are we regarding.

A

The rules here so the idea was to bias instead of instead of taking the rules as the patterns that I had suggested. We stay with Jenkins, more common way of doing things, which is, if a plug-in specifically focuses on delivering a capability to a particular keyword github in this example. It would be labeled with that, but in this example, basic branch build strategies would not be labeled github, because it's not something.

C

Thank you. That is what I would also have suggested, because what would happen is basic bench. Build strategies would get two dozen labels for every implementation of SEM that is compatible with it, and that would seem very weird to me. So I agree with this. I only have ones other specific feedback. If I may.

C

I, don't think we should, and this specific example, that's currently being screen shared, looks like fairly strict, restrictive rules about plug-in labeling, which seems to go counter to where we're going with the labeling by supporting github topics, which is a lot more organic and allowing people to just you know, add labels, they think make sense within the whitelist constraints. Obviously, but there seems to be a tension here between.

C

We want strict control, that's the correct label that would be an incorrect label and, on the other hand, I mean we support, get up topics you can define your own just do whatever and I'm, not quite sure what the direction here is.

A

Well so, and my intent in describing these was only to give samples and not to state them as rules, rather as samples and I think, given the guidance from both you and from Oleg that we should be more more more jenkins style of, let's be accept that this will be organic, that it will be flexible.

A

So what I was thinking I should do is offer a pull request to the to the developer Docs page on hosting that says that hey, you can use labels and you should choose the labels from the whitelist and you may and bias towards, and you have bias towards fewer labels, not not being overly broad and focus on the value that your plug-in is giving to the user. So keep it very simple. No, no strict rules describe no no rigorous enforcement of anything.

C

But as in addition to that, I think it makes sense to encourage users to propose new labels to be whitelisted, because I mean we don't know everything. Maybe a new niche is created in terms of Jenkins plugins. Multiple plugins like if you think back five user is something there was like, probably like one blocker plug-in or something, and at some point there would have been this critical mass of five blocker plugins, where label makes sense, so yeah totally agree, and that makes a lot of sense.

A

Okay, so let's see, if I can capture that I'm gonna actually put it into an action item here so mark to submit mark, submit a PR to the dev Doc's.

A

That proposes that says it hub topics are supported and encouraged.

A

Topics that match of whitelist.

A

Will be displayed on plugins instead, I o.

A

Encourage proposals and encouraged proposed proposals to add to the whitelist.

A

And suggest that.

A

Labels focus on the key value provided to the user. Is that a reasonable way to say it or how would you, how would you suggest I.

D

Suggest using a word other than key there, ah oh good! Okay, how about just that yeah that works right.

C

Basically, what we're trying to say here is labels are when users are looking for something or administrators. Are you looking for something, but they don't know exactly what they're looking for, but rather you know the general topic, the category the technology stuff like that and.

C

Yeah, so labels should focus on that. Nobody cares the technology about the technology that your plugin is implemented in right. But if you or the build system that you're using so limit your use of the Maven label to you know maven specific features in jenkins and not you know, because you have a pom.xml right.

A

Well, it work or I, like the the one that Oleg and I discussed earlier was. It should not be that the that every plugin that extends pipeline uses the pipeline label, because if every plugin that extends pipeline uses the pipeline label, the set of labeled pipeline, the pipeline label will become almost useless. There are so many things in it is that.

C

A very example Daniel earth, right by now pipeline as a label, is akin to labeling of Jenkins plug-in using Jenkins and plugin right, exactly no sense inside Jenkins right.

A

C

This pipeline or whitelisted label- it probably is right.

C

Okay, yeah yeah.

B

Whether it's anybody, it's a arguable topic, because right now, that I mean is 60 or so plugins, but the in principle that is labeled from it.

A

Although that with only 60, that's not as bad as I had feared, because I think if we looked at implement those who are implementing pipeline, it's probably double or triple that yeah.

B

Because not everybody puts on the pipeline topic but see easy yeah. This so I either spend some time to clean up common labels like kubernetes, aber WS open shape it all in whatever, and that's some time to put this github topics but yeah, please be sure that I wasn't going through Python against because practical, where you're for this label is not that high.

C

Maybe maybe something like the following makes sense use labels for if the plug-in is well above average related to the label, because if you just implement simple, build step in our pipeline compatible, that's not develop of average, but if you're you know an actual pipeline plug-in, then the label would be redundant, but it wouldn't actually make sense something along those lines. Perhaps good I, like that guidance, excellent and and I mean ultimately it's it's not just it's just that.

C

What's the philosophical do what everyone would be able to do and the outcome of that would be reasonable if everyone labeled their vaguely related plug-in with pipeline, the label would be useless.

C

So maybe we can work this nicely to explain the principle good.

A

Yeah I like that, okay.

A

Thanks excellent: okay, thanks for the extra time here, I propose we move on to the next topic. I think I've got I'm settled on the on the discussion. The next stop will be a pull request. Any objections to that.

B

If it's fine I saw wanting Commission, would it twist the reserve from the documentation you crave that Jenkins github or Cardenas reserve their right to manage labels for plugins without asking for permission so, for example, in the case of it have topic render lism or in the case of when we just feel it's visible, add a label. I, don't know anything else. We can do that without consulting.

B

It seems very reasonable yeah it does yeah, it's not how we commonly approach the flag in ecosystem, but since say it goes directly to updates under make it something.

B

A

I think I think shape, saying may or are allowed to is it's very fair I think that's a reasonable thing to tell them that if, if there is some reason and typical or guide means, don't don't act back that way unless there's a motivating reason: good thanks.

A

Okay, next topic, new plugin adoption and deprecation processes, Oleg did you'd like to take us through this one. Yeah.

B

A

Sharing, oh.

B

Okay, I spent some time to paint pages before the meeting and then I closed everything. Okay, this my screen do there's eggs okay. So when we here, let me show you labels how they look on the plug inside, because we spoke a lot about how to label it. But here from the users perspective, it looks like that you can look for plugins and here you can discover plugins, which are rated to kubernetes. I just launched a search, and here you can see it is 18 plugins.

B

You can see that there are labels, so not all plugins are labeled so far, but is still some technical depth jumps of labelling. Look! If you want you this bugger, you can also discover plugins, which are delete rubberneckers and you can do it for common queries. So we spent a lot of time updating white list, so you can find it yeah the recent apps key in there, but we build we just hope to make bringing discoverable.

B

There are two specific cases related to plugins. At the moment, one is duplication, so it's duplicated plugins plugins, which are no longer supposed to be used by users and you to whatever reason this instantly doesn't include the publishing plug in the published plugins. But, for example, will that change security KEMA decides to do publish reading because of the critical issue.

B

If we only three gets removed from the agendas of this Center, because maybe else decided to so when this plugin is not listed but better sound for years, fish ear still connects installed but which America is duplicated, and if you navigate, you get a warning that gets duplicated so with what we had on a week and what we have now on the plug-in said same for plug-in adoption. That is, a special label called adopted.

B

This plug-in, which basically lists for plugins, which are for adoption and right now, are there are 77 plugins, which a mark like that, but there's a pull request from Daniel, which adds couple of hundred more also have a follow up to the task plugins from and needs to lead to leave this list, but at least it makes an egg in is discoverable same here. You get a woman, yes,.

C

All of Nikolas plugins should be my pull request because I bet removed him from the uploaders list in response to his devilish threat. So when you said he's formerly a maintainer and you contacted him, he wasn't. He was already removed from the plugin. Okay.

B

So yeah the problem that he's not explicitly mark the plugins are not explicitly marked for adoption. We have this case for dr. Java ek, a believer, so it's not a Java plug-in which is used, for example, in dr. plug-in, and we are this plug-in use the market for adoption. But now we know that it's up for adoption and, for example, how to fix it quickly right now using github topics.

B

If you have right, clinicians is in the repository you can just put adopt this plug-in label and after that you just save it and after some time I think it's a bit tentative. You pick it up. It takes a while now, maybe up to 24 hours. It has some notion of eventual consistency because plug-in my installation manager on the static side. It has multiple containers, running, conserve and cut it close.

B

So sometimes what everything gets updated at once, but eventually you bet it'll eat it and you will get this label on the plug-in interface and if you are plugging linking it, it's just a few peaks and within each hub and you get it ranked so yeah, that's how it works. So here you can see that there is dr. dub, it is epi plugin and that is adopted this plug-in label.

B

And if you go to the plug-in interface now we see that Everest, epi, plug-in and okay, so both of these labels actually came from github because we are not leaving them at some point and yeah. That's how common engine works, going back to adoption and duplication. I spent some time to the the produce yeah, it's basically at one github topic, but we needed to make read the old guidelines from Mickey I also took them put them according to the current process. So on the Jake is the communication side.

B

Now you can find a refresh to the communication which targets it have specifically with you, references labeled deviations as a plan-b, so you can go and set up a label explicitly, and there are these centered resources. If you don't want to use github topics, sometimes it's reasonable, for example, there might be a duplicate again, it is archived code and basically you just can't set a github label or you have a multi-modal repository and you want to duplicate on their particular plugin.

B

Again, you cannot do it using github topics, but for such cases you have an escape hatch like this file. Well, the most of these labels, edit for historical reasons when we are migrating out of me thanks Daniel wiki generated this file, so this fire was basic towel down or for labels set up on the weekend.

B

Our adoption processes document some other bits so, for example, common topics.

B

How can I mark like in folder option- and it's not only about setting a label, we also to comment of the documentation if you want to set specific information, for example, and actually we can talk home idea or something like that, and you recommended to send a message to the mailing list, because we had cases when somebody wanted to step down, then you sent a message and you find new, my peers, who are interested so instead of just stepping down in disappearing view and organize some knowledge transfers and it helps at the coming in tailored and yeah.

B

There are also other silage beets, but basically all this information comes from nicky and it was facelifted to their claim the new process and it you can also a to remove this quote internally, because it's not the needed. But if the declaration is up to date, it's exactly the same for duplication and the removal of leggings. So we spend some time to document it again.

B

You just put a topic: it's recommended to update click in the communication, to highlight why it's duplicated and then it's recommended to release the plug-in because the injects crisis and we rely on the conditioners called coming from mid half. So our recommendations when we duplicated the plug-in you actually do a final release so that people can see that this documentation on the content.

A

Well and I believe that, for instance, when Feinberg's plug-in and PMD were deprecated in favor of warnings, ng that final release gave some hint to the user. Didn't it didn't it hey, but the new plug-in is this week.

B

I'm gonna take a look so here one interesting thing: you can see that that is dedicated and that is gemstone or igneous applied to by I believe so here, yeah, the plug-in has breached end of life. So that's it and I believe that the EA it comes from it hub and I believe we did it without actually using the plug-in, because it's also possible to just go to update Center, had to supply a target like a wiki URLs bill.

B

So all those who are not familiar Tibet but is a file called VQ of the right where you can basically set custom locations for the communication sources. Even the common agenda still discovery engine doesn't work, and here you can see that this is a patch. By will be so. He just thought he directed under all the plugins today.

B

Basically, it happiness I visited releasing this plugins I did the same later for JavaScript libraries, and here you can see that any actually reference a readme file not on the root, but it still works and I believe that in the future you need to get rid of all this stuff and emulate it too.

B

We get contributions, so we didn't even make great a big things, so I hope that at least we finally contain only get happy or else for billions fishing on you only used.

B

Thank you, okay, so I guess so. Let's eat this adoption in duplication and everything is recoverable, but the guidance here and there are plug-in making us who we exactly. That will be much appreciated. Our.

C

Side note on the brocation my currently have poor requests in flight. That would slightly change our deprecation works.

C

Specifically. Deprecation would also be possible for plugins that are no longer being distributed by benefit is if a Jenkins instance has plug-in installed right now. The problem is: if we then suspend distribution, we cannot provide any information about that plug-in anymore.

C

Other than security issue modifications and the pre creation specifically would work similar in that it would not be part of the regular available version metadata, but rather decided, and that would allow us to show deprecation inside Jenkins, even for plugins not currently being distributed, and the current proposed approach would also have a application URL, which would probably typically linked to plugin documentation, but there can be other sources, for example, and this has been plug-in distribution because of a security issue, so that may change soon.

C

As I said, it's currently open for requests and may or may not change. I.

B

Think it's a great improvement because right now, if you the publish button you can at all and if you generate Tom stones, it will be helpful for everyone thanks for doing that. Yes,.

A

So so Daniel, then, what you've that your pull request proposes a a UI improvement to Jenkins that will, for the user, actually tell them that they are using something that is now deprecated I.

C

Mean in that it already exists to an extent is I mean there is no pull request by Tim, I think or Joseph I'm, not entirely sure right now, who implement that too straightforward way is similar to how we recently did adopt this plug-in.

C

Where you look for the plug-in label in the updates in the metadata.

C

Yes, that's that's it, and if the label exists, you highlight it very visibly in Jenkins, with an admin monitor and such and my feedback to that pull request in its current form. Is it's not enough, because we need to label plugins that are deprecated and I'm no longer being distributed, and so there are two parts to this.

C

One part is the server-side and updates in the two in which we need to add an additional kind of data to the updates in the JSON file and allow it to be configured we, our property file, our JSON file or whatever nobody cares so that you can also add the label to plug-in. So this distribution is currently suspended, that's the server side and then client side. We need to extend Jenkins to consume the new metadata and adapt traditions, pull request to make use of new metadata as well mm-hmm.

B

Yeah, so it's in a little cycle to what we need for a lot of labels and metadata beads. Look, it's quite straightforward. Got.

A

It okay! Thank you thanks for that clarification, so it's the your poke. Pull request is really about getting the extra data for a type of thing that does not exist today in Jenkins. The notion that a plug-in has been removed from the update center and we need to alert them that it was removed that has been D published, but.

C

Because there is some overlap between a public plug-in was publication whose publication is suspended or distribution was suspended and deprecated plugins and the current approach with the deprecated label that's implemented in the pull request and I mean between the extend. It's also implemented right now in Jenkins, because you can look at what deprecated label is, but it's not highlighted in any way.

C

You will only see that for plugins that we currently distribute and that's a way above average chance that the plug-in that's deprecated is also no longer being distributed, because if the service it integrates with has been shut down, there's no reason to continue distributing it other than to inform users that well you this plug-in no longer does anything and can be removed. So yeah, it's it's yeah, that's! So that's the ignore list and there's a bunch of stuff.

C

Many of them do to services being shut down, but if you got renamed back when that was easily and accidentally even possible, because we had no fine-grained upload permissions years ago, specific specific releases, don't really matter and then of course, there's plugins that are suspended because of your security vulnerabilities.

B

So this list is quite long. Yeah.

A

And there I am I can see myself right in that list. Yeah. Thank you. Oh okay, that's severe severe problems are expressed in this. This list, yep.

B

Yeah, whatever okay also.

A

C

B

Exactly anyway, this distant helps really.

B

So yeah thanks Daniel for the heads up I think it would be a really good improvement for the tooling.

C

But and while we're talking about adopters plug-in, that's not all I think already in the latest weekly here.

B

You mean adopt this label visualization yeah, that's in two.

C

To twenty seven.

C

So also related to this, and it was just simpler to do than the last one there I have screenshots so yeah. That's why you just get! Hopefully this because.

B

It's easier to make it they do requests containing screenshots.

C

The link is also in the Jenkins changelog, so yeah. This is this. This works similar to what jettisons current pull request is for deprecation, because if, if some things up for adoption, it's typically not suspended. No, that's not true a hundred percent of the case, but a hundred percent of the time, but I think it's close enough that this one makes more sense to have for just distribute the plugins, and we can always later extended this more.

C

B

A

Yeah, so that the next LTS that this will be included in is probably three months away right, so this will. This will have time to soak for a period of multiple weeklies great. Thank you.

B

No other changes so yeah. Let's you waiting, whoops, okay, we are slowly dying, cut off time for this meeting and we still have two items on the agenda so mark. What would be your proposal about them so.

A

Let's I'd say: let's take on, let me get a look at those agenda items.

B

Jenkins told my friend, google season of dogs I'm, not.

D

B

Of them can be discussed in a couple of minutes right.

A

Well, let's, how about I had intentionally to set this meeting back to once every four weeks? What if we say, we'll meet again in two weeks and discuss those two topics: is that well actually season of Docs I love hmm so Oh, like roadmap yeah,.

B

Yeah, if possible, I would prefer to discuss it next week or start lesson. Promos discussion and I made increased because we can price eat a lot resulting in there. Yeah.

A

Let's I think, let's do roadmap discussions on the mailing list. It's a good place to do it and I would like to do I think the same thing with season of Docs in part, because I would love for the Jenkins project to be part of season of dogs, but I personally, don't have capacity to run google season of Docs.

A

So what I was going to do is post a remaining list, that we think it would be a good thing, but it's not gonna work if I have to run it, and so, if someone would like to assist and and lead the effort, google season of Docs is a fascinating opportunity. That Google provides to encourage professional technical writers to who may not have open source experience to contribute to open source. It's different for me than then Summer of Code right.

A

It's it's not targeting students, it's really tiring with people who are already in the technical writing field, but therefore it some different needs and some different expectations.

B

But anyway, the mentors because engaging is open-source community is completely different from professional duties or from freelancing in terms of communications. In terms of how things happen, the Cardon's changes being integrated, so we still need Mentors well,.

A

Then, even even though I think of one of one of my colleagues make McRoberts is on online with this, she comes from a tech, professional technical writing background, and it was not a familiar thing for her when she first started contributing to open source, and so just things like introducing technical writers to get and how we interact through git is already a subtlety. That's.

D

Not true, actually I had worked for three other places where we used guild, but everybody does it slightly differently. This is the first place, that's used Forks and it's I'm sure. If I don't have profound knowledge of git and then it all makes sense, but so it was all different for each place so, which is it also? Some of the other technical writers went into back.

A

To back to Oleg's point that open source contribution is really different: yes, okay, so Oleg did that address your two questions on those last two topics: let's do them by mailing list and and if it's a final great all right, those are all the topics that we had for today. Anything else before we close the meeting.

A

All right I will flag the action items and post the recording thanks. Everyone we'll see you thank you meet again in four.

D

A