search

Raku / problem-solving

🦋 Problem Solving, a repo for handling problems that require review, deliberation and possibly debate
Artistic License 2.0
70 stars 16 forks source link

Managing the Raku project as it is Coming of Age #203

Open lizmat opened 4 years ago

lizmat commented 4 years ago

As Jonathan pointed out in one of his replies on #200, Raku code is being used in production and we should therefore make sure that we don't break stuff, even more so than before. On the other hand, the Raku project currently lacks visible day-to-day leadership. It still feels like a hobby project, in which the research aspect is more important than the actual production usage. It definitely projects itself as such in some places.

Stefan suggested introducing the 5-3-1 rule, to prevent the pumpkin from burning out and preventing contributors from being disappointed and leaving (paraphrased from "It leads to burned out managers and disgruntled employees because they won't get service on the level they're expecting.").

Jonathan countered with:

One of the challenges for me is how to set expectations on others to make things scale better, in the context where others are volunteers. That's where the manager analogy breaks down. At $dayjob, I sure as heck try to make sure I give people the tasks they'll find most enjoyment in, but at the end of the day everyone understands that, well, it's a job, and sometimes we all have to grunt our way through the grunt work that we'd rather not have to do.

This made me realize two things:

But I disagree with one point in Jonathan's premise: I do think that volunteers also understand it is not all fun and glory when you're contributing to a project such as Raku. In fact, I'd argue that people doing documentation are a prime example of doing grunt work as volunteers. And I'd also argue that I've done quite a bit of grunt work myself (think Weekly). I also would like to mention people doing booths at open source events. If anything, this needs to be about clarity of expectations for everybody involved. So applying a 5-3-1 like-rule would definitely be a possibility also in a volunteer project!

S01 about project management states:

Mostly, we're just a bunch of ants all cooperating (sort of) to haul food toward the nest (on average). There are many groups of people working on various bits and pieces as they see fit, since this is primarily a volunteer effort. ... But above all, our project plan is simply to help people find a spot where they can feel like they're creating the future, both for themselves and for others. Around here, that's what we call fun.

Jonathan refers to it like this in a private conversation:

Which effectively suggests a "bottom-up" approach to (not) "running" the project: people do the things they find most fun (thankfully, some of us have rather unusual ideas of fun...) Does it work? Well, it's given us the Raku language, Rakudo, MoarVM, infrastructure for not breaking people's stuff when we ship releases, a lot of docs, a lot of modules, a lot of IRC bots a lot of friendships...things could be worse.

But could things be better? The context has changed somewhat from when S01 was written. The nest to haul food towards (on average) was clear: have a "1.0" release of the language together with a compiler and runtime for it. What about now? Admittedly, while there's plenty of clear needs ("it needs to be faster", "it needs to have less bugs", "it needs to be more reliable", "it needs more modules", "it needs to be better documented") most of those are continuous, rather than being a destination. Is that what is missing? I mean, for me, "keep making things better" is a pretty good direction to be going in - but perhaps we also need to identify the next nest(s) to haul food towards (on average, at least).

I would therefore argue that it is time that the Raku project should be lead more like a business, then just as a free for all place to try things out. Although there will always be that aspect: e.g. many aspects of MoarVM can be considered CS research level.

But in this world where things are starting to shift in major ways, and personal valuation is changing, we need a better way of running the Raku project. Think a majority of people working from home, think social media standing, think how "basic income" might change volunteer demographics.

lizmat commented 4 years ago

I think we need to create a "Project Lead" role for the Raku project. The "Project Lead" role would need to take care of day-to-day management of the project, such as:

The role of the Pumpkin in this situation, would become more a "product owner" role. Telling the project lead: what is wrong, what is right, what needs to be fixed, and for each of these, why. And the project lead should then take care of that. So the role of the Pumpkin would become monitoring that the Project Lead is doing the right thing, rather than the Project going in the right direction directly.

The Project Lead role would need to be renewed once a year, to be agreed by the active committers. The Pumpkin always has the right to "fire" the Project Lead.

The Project Lead role may well be a full-time job. It is foreseeable that it may come with some financial compensation from sponsors, possibly crowd-sourced.

I would like to make clear that I would make myself available as Project Lead until at least 1 January 2022. And that once this role is established, we should look at the definition of other roles and adapt them accordingly.

JJ commented 4 years ago

I think we need to create a "Project Lead" role for the Raku project. The "Project Lead" role would need to take care of day-to-day management of the project, such as:

* being the main assignee for problem solving tickets

* monitoring tickets in the various repos, making sure they adhere to 5-3-1 rule where applicable

* assigning tickets to others where possible, needed

* keeping track of progress of tickets

* rejecting tickets if not meeting guidelines, while telling submitters how to do them properly

* monitoring social media, if not directly, then indirectly

* interfacing with Open Source organizations, such as TPF

* in general: be the first goto person for people with questions / issues

* and handling any other day-to-day issues

Apart from that, all my support.

nxadm commented 4 years ago

Stefan suggested introducing the 5-3-1 rule, to prevent the pumpkin from burning out

Preventing the pumpkin (or technical lead) to burn out is something very important, not only for the project but also for the human being behind the role. I can only imagine how heavy the burden must be of everyone looking in your direction all-the-time.

While splitting the burden by assigning more formal roles is a great idea, the long list of "grunt" tasks for the Project Lead puts him/her also in the danger zone for burnout. So, maybe that role should be split as well in time. Assigning roles and responsibilities may yield great results, it all depends on the available candidates. Some task require specific knowledge, limiting the pool considerably. Also a good relationship is needed between the roles so no conflicts arise. Is @jnthn positive about delegating tasks, can we make sure it will not generate more work for him afterwards?

If the new role is accepted, I think that @lizmat have proven time and again that she would be a great fit (and not having to combine the role it with a day job helps with the long list of tasks).

lizmat commented 4 years ago

@jnthn has indicated to me that he'd like to explore my suggestion.

AlexDaniel commented 4 years ago

Looking at the list I realize that in the past I ended up being the person doing some of the mentioned tasks. I'm glad that now there will be a defined person working on these things.

jnthn commented 4 years ago

Preventing the pumpkin (or technical lead) to burn out is something very important, not only for the project but also for the human being behind the role. I can only imagine how heavy the burden must be of everyone looking in your direction all-the-time.

It's weighty, but at this point, certainly still net enjoyable. It's sustainable mostly because I look at it as a marathon, not a sprint. I've been working on things around the language for at least 12 years, and know how far we've come in that time, and I guess the perspective helps. Yes, it took a while to get where we are today, but I know full well that the worst releases we've shipped and the worst decisions we've made were when we hurried.

I understand some are driven by immediacy and responsiveness; by contrast, I try to maintain a healthy distance from the urgencies of others. :-) I suspect that leads some to think I maybe don't care much about, for example, the numerous language issues posted here; the reality is that I do, but caring to me means moving slowly and understanding (some times more than others...) what I'm doing. There aren't dozens of isolated language issues here. There's a web of inter-related issues with various dependencies on each other, on things that need to happen with Rakudo/MoarVM, and so forth.

Is @jnthn positive about delegating tasks, can we make sure it will not generate more work for him afterwards?

I think much of what Liz is proposing involves trying to help others get more signal and less noise, and certainly that's something I'd appreciate - while at the same time recognizing the burden that places on Liz if she takes up that role for some time. It might also help bridge the immediacy <-> sustainability gap.

The role of the Pumpkin in this situation, would become more a "product owner" role. Telling the project lead: what is wrong, what is right, what needs to be fixed, and for each of these, why. And the project lead should then take care of that. So the role of the Pumpkin would become monitoring that the Project Lead is doing the right thing, rather than the Project going in the right direction directly.

I'm a tad uncomfortable with the "Pumpkin" terminology, honestly. I'd kind of like us to try and tease out what the various roles are, and name them. I mean, at the moment, what roles am I playing?

I guess "product owner" kind of captures the last of those. The thing is that there's never been a point where I said, "oh, that's my role to play". Much as that never really happened with the language design issues; I just saw a need and tried to help, and now seem to have the hat...

Anyway, in closing, I basically like what Liz is proposing. It'd be good to try and define the various other roles that exist too, and how they relate. I think it'd be good for the vitality and longevity of the project as a whole if some of the roles I play are, when there are folks willing and competent to do them, handed off. After all, there's one of me, there's only so many days in the year to give to each of these roles that could all easily be a full-time job in themselves, and I do have to cross a road each day that is used by both trucks and buses...

lizmat commented 4 years ago

https://opensource.com/article/20/6/open-source-project-managers (just for reference)

autarch commented 4 years ago

As an outside party reading this, I have one (hopefully useful) thought to contribute. If you look at how many other languages do this, you'll see that many of them have groups in these roles rather than just one person. For example, Python recently moved from having Guido as BDFL to having a Steering Council with multiple members.

The Python model is just one of many variants on this idea, but I think there's a lot to be said for having a small group of equals in terms of sharing the load.

lizmat commented 4 years ago

I think the idea of having multiple people performing the leadership role has merit. But to an extent, that is exactly the problem that we're facing in Raku now. As long as we do not have more people involved in Raku, I think it's better to have a single person be primarily responsible for a role, and a second person secondarily responsible if the primary responsible is away or otherwise unable or unwilling to perform the role.

I will therefore start multiple PR's for each leadership role separately, so we can discuss them separately and hopefully agree on them.

Currently I'm thinking about these roles:

Some of these roles are highly technical, others potentially have no technical content at all. If a role is not filled, it will be performed by the overall project lead until there is someone to fill that role.

JJ commented 4 years ago

Plus...

And probably

nxadm commented 4 years ago

Marketing and user experience lead (this would subsume web presence, I guess, or maybe a different thing. I don't know. Maybe "web presence" should be "web infraestructure" and marketing a different thing. Again, I don't know...)

In my world view is marketing and user experience pretty much unrelated in the best of worlds, and often orthogonal in practice. User experience may be close to the architect's role but always with the end user in mind.

vrurg commented 4 years ago

It already feels like too many roles, but 'release manager' is actually two roles: 'Rakudo release manager' and 'Raku language release manager'.

Otherwise feels right but dangerously bureaucratic...

* Community modules project lead.

Better be part of ecosystem role.

* Marketing and user experience lead (this would subsume web presence, I guess, or maybe a different thing. I don't know. Maybe "web presence" should be "web infraestructure" and marketing a different thing. Again, I don't know...)

If PR above stands for 'public relations' then, apart to use experience, this can be merged with it.

Altai-man commented 4 years ago

It already feels like too many roles, but 'release manager' is actually two roles: 'Rakudo release manager' and 'Raku language release manager'.

This. Releasing MoarVM+rakudo is one thing and preparing language revisions is a rather different thing.

bazzaar commented 4 years ago

Perhaps it might be better to draw out a simple structure of a few loosely organised teams that will be expected to work collaboratively with each other, for example like so :

Project Management team

Language and Implementation team

Continuous Improvement team

Customer Focus team

AlexDaniel commented 3 years ago

Related: https://github.com/Raku/problem-solving/issues/237

2colours commented 1 year ago

We are essentially in the same position, except without any person to "drain" on Problem-solving issues. In retrospect, it's easy to understand how it became a habit to deflect issues or just simply ignore them.

There were so many ambitious (and actually good) ideas in this thread. It's still not too late. A good first step would be to be transparent about the status of infrastructure...