а менеджер знаний == хранитель знаний или !=

мне кажется, менеджер - это шире
он не только хранит, но управляет процессами

Вакансия конечно хорошая, жаль что только офисный режим - сужает ареал обитаемости.

@M_Baranovskaya У вас https://midhub.io/ru/learn-more/about-midhub# не работает. Вдруг полезную вещь сказанулЪ.

Все верно!

Спасибо, сейчас проверим

Странно, у меня работает 🤨

куда мы идём

Здравствуйте! Вот такое задание поступило от начальника: "С 15 года мы работаем над несколькими окрами. По текущий момент их количество увеличилось.
И только с 20 года ведется четкое деление по проектам. Но проекты это не ОКРы, если их не зафиксировать документально.
Т.е. надо создать приказы на открытие ОКР, прикрепить к ним какие-то еще документы. Какие? ТЗ, отчеты? Даты когда появляется продукт и как потом оформляется выпуск.
Потому что из части их и созданы как раз продукты (лицензии), наши Опции, которые мы продаем.
Может еще что умного скажешь, подучишь меня, пришлешь что почитать, включая и как это в бухгалтерии оформить можно." Нашла в ГОСТ Р 15.201, что заключается договор (контракт), затем ТЗ, КД и ТД, при приемке этапов составляются протоколы/акты.  Коллеги, прокомментируйте/подскажите, пожалуйста, что почитать и может из личного опыта подскажете что нужно.

Привет!
Подскажите, насколько допустимо в англоязычной документации использовать should?
Например, The Sign in with GitLab button should appear.
Правильно я понимаю, что лучше will appear?

у вас СТО на разработку ОКР есть?
а так, да, читать ГОСТы серии 15 и ГОСТ РВ

нет, СТО нет

ОКР инициативный? Нет контракта? Внутренний приказ нужен на начало, раб группу проекта

да

Можете уточнить - да, использовать should допустимо или да, will однозначно лучше?

will конечно. should — обязан, должен.

а почему нет?

Документ переводили с русского, видимо, калька. "После этого действия должна появиться кнопка".

ну и по-русски так тоже не стоит писать. должна появиться, но может и не появиться. если не появилась, перезагрузите весь дата-центр

Зависит от действия. Если всё совершенно линейно вида «сделал X => появилось окошко», как у вас в примере, это will.
Если возможны обозримые ошибки и осечки, то should и пояснения. Например, это для случая, когда некая опция регулярно бывает недоступна по штатным причинам, поэтому там может вместо нужного окна появиться ошибка. У меня в практике есть такая штука, например.