> Isn’t this the point of project management; to avoid this issue?
Is the point of project management to avoid the problems caused by project
management? That feels like a Dilbert cartoon.
To be clear, I'm simply responding to the apparent suggestion that we assign
every 4.0 ticket to somebody. These tickets will be worked on when
contributors have time, but assigning them makes it harder to self-organise
their delivery. As far as I can tell, this is creating a project management
_dependency_, without solving any exigent problem.
Also to be clear, there is no role of "project manager" to step into, back or
forwards. We're all equals here, and we have to be careful to maintain the
ability to self-organise our work. Any help in this area should aim to
facilitate without developing a dependency on the service.
On 10/01/2020, 19:23, "David Capwell" <dcapw...@gmail.com> wrote:
I also find that assigning tickets to people when they have no bandwidth to
implement them is counterproductive.
Isn’t this the point of project management; to avoid this issue?
Lets say there are 10 blocking tickets for 4.0, and they are all on you; a
PM could help by finding others who could help out and make sure that no
one steps on each other.
At the same time, PMs help give visibility into how much work is left and
are previous time estimates off (we expect M2 done January, are we close?
Do we need to punt things to M3? Do we need to load balance to make this
date?, etc.).
I don't think anything is currently languishing because nobody realises it
needs to be done, but if you can get things magically moving faster, I will
of course be thrilled! __
So lets try and see what happens! =D
On Fri, Jan 10, 2020 at 11:12 AM Mick Semb Wever <m...@apache.org> wrote:
>
>
> > One thing I'd love to see
> > again is a regular (every two weeks?) update on progress on the dev list
> > (similar to what Jeff Jirsa used to send around -- it also included a
> call
> > for reviews iirc).
>
>
> Yes, I also miss those fortnightly (or monthly) summaries that Jeff used
> to do. They were very useful "glue" in the community. I imagine they'd
also
> make writing the board report easier.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
