Modernize work-process.md (#356)

* Modernize work-process.md

* Update 2_Operations/work-process.md

---------

Co-authored-by: Dejan Murko <[email protected]>

2_Operations/work-process.md

@@ -2,28 +2,24 @@
 
 ## Schedule
 
-* Every **Monday** we have a [meeting](https://github.com/teamniteo/handbook/blob/master/2_Operations/kanban.md#monday-meetings):
-   * 12:00 UTC for the whole company in the #operations channel huddle followed immediately by separate meetings for the projects in their own channel huddles.
+* Every **Monday** we have a [Monday Meeting ("MM")](https://github.com/teamniteo/handbook/blob/master/2_Operations/kanban.md#monday-meetings):
+   * 12:00 UTC for the whole company in the Niteo Zoom room followed immediately by separate meetings for the projects in their own Zoom channels.
 
 * Every weekday Niteans should check their [GitHub notifications](https://github.com/notifications) so that they don't miss things that involve them.
 
-* A [Developer Session](#developer-session) is scheduled when we have a fair amount of items to talk about and is typically held right after the Monday Meeting.
+* A [Developers Session](#developers-session) is scheduled when we have a fair amount of items to talk about and is typically held right after the Monday Meeting.
 
 Niteans are encouraged to take Fridays off for a long weekend. Same as any other vacation off, make sure that your backup Nitean is available to handle any potential issues (see [Vacation policy](https://github.com/teamniteo/handbook/blob/master/5_People/benefits.md#vacation)).
 
 ## Quarterly Review and Planning
 
 Every quarter we take time to review, reflect, and plan for the next quarter. There are three tasks for the Quarterly Review and Planning: Partners Meeting, Quarterly Review, and All Hands Meeting.
 
-## Developer Session
+## Developers Session
 
-We are a remote company and as such sharing of ideas and lessons learned is impaired by the fact that we don't have the time or space to do that effectively.
+We are a remote company and as such sharing of ideas and lessons learned is impaired by the fact that we don't have the time or space to do that effectively. In the long term, this is hurting everyone and as such the Developers Session is a way to discuss recent ideas, questions and novelties.
 
-In the long term, this is hurting everyone and as such the Developer Session is a way to discuss ideas and questions that might have arisen lately. Followed by a short lightning talk(s), which can be impromptu or declared beforehand so others can join.
-
-You can learn something from every single person in the world, no matter what their opinion on any topic is. We also believe that this is a big part of open source and our company, being able to learn and collaborate with people from all over the world who have a wide variety of different opinions on how to do things. On the other hand, a lightning talk can be a perfect way for testing how people react to a talk that you are going to have at next conference or just getting rid of that presentation fear in front of people.
-
-In order for things to not explode, the Session is limited to 60 minutes.
+In order to prevent excessive [bike-shedding](https://en.wikipedia.org/wiki/Law_of_triviality), Developers Session is limited to 60 minutes.
 
 ### Agenda
 
@@ -39,10 +35,9 @@ As an attendee, ask yourself:
 
 As a curator:
 
-- Organize which time to have the session and annoince it in #development when it's time to join and which Slack huddle to use.
+- Organize which time to have the session and announce it in #development when it's time to join and paste a link to the Zoom room.
 - Prepare a joke or something funny to share.
 - As a curator, meet and greet everyone, especially first-time joiners.
-- Announce who is having the Lightning talk if one was prepared.
 - If you hear crickets, start rolling the ball with a question, an anecdote or a funny story.
 - Make sure no one is talking the whole 30 minutes, everyone should have an opinion!
 - Write a report into the **Recurring** ticket for the meeting.
@@ -59,4 +54,4 @@ When a User Story or Pull Request is getting close to being completed but there
 
 Big cleanups (of code, documentation, or anything else) happen rarely. They are hard to organize, and to motivate for. Instead of doing big cleanups every few months (years?) when pain levels are high enough, we prefer to do constant tiny improvements with an approach called [Continual Improvement](https://en.wikipedia.org/wiki/Continual_improvement_process).
 
-For Niteo, this means that every Pull Request (except Priority Lane issues) should include at least one minor cleanup commit alongside the main PR commit. It does not need to be related to the main commit, it can be improvements for anything in the repository, however trivial. This can include code and documentation updates, typo fixes, or removal of something that no longer makes sense.
+For Niteo, this means that most Pull Request should include at least one minor cleanup commit alongside the main PR commit. It does not need to be related to the main commit, it can be improvements for anything in the repository, however trivial. This can include code and documentation updates, typo fixes, or removal of something that no longer makes sense.