[Bf-committers] Modules simplification (and members cleanup)

Julian Eisel eiseljulian at gmail.com
Wed Nov 20 15:39:53 CET 2019


Hey Dalai,

sorry for taking that long to answer.

I talked to some other devs about this and I think I now understand
what the changes intended to do. The current naming doesn't convey
this intention at all IMHO, so I suggest we work on that.
It also seems to me there were misunderstandings regarding the role
changes during the meetings we had here. On my side, but probably also
on other's.

One thing that Sybren pointed out is that we should have a very
precise definition of the roles first. Let's make misunderstandings
hard. Then we can come up with suiting names.
What happened now was the opposite: roles were simply
introduced/changed in the modules list, but the new role descriptions
were not given (https://wiki.blender.org/wiki/Modules/Roles still
needs a big update). Not saying this to point fingers, just proposing
that we do it differently if we reevaluate now.

Now to the concrete roles.

1) Member
With the definition you just gave for that role it sounds like a
reasonable one. Just one question: Aren't they responsible for making
decisions too?
"Member" sounds like a horrible naming choice for this though :)

2) Owner/Coordinator
I'm all for having a single person as a contact/coordinator person. We
need people who feel responsible for that stuff, so it's a good move.

>From talking to other devs however - who were apparently involved in
earlier discussions on this topic - they seem to believe too that this
person would get special decision making powers. I still find that
idea problematic. And seems like we need to clear up if that's the
case or not.

My concern is still letting them turn into the module's "benevolent
dictators". The efforts of reasonable arguments within the team should
be in the foreground. If the team fails to deliver in a democratic
way, at some (late!) point I'm fine with a single person taking a
decision. That should be the exception though, not the norm.
Other devs agreed on this point.

3) Developers
I appreciate the proposal for Pablo and me to become "members". That
proposal wasn't clear to me from the PM. This solves some of the
immediate problems.

There are still two points on this though:
* The role name "developers" is still odd. Again, I suggest coming up
with a formal definition first and then checking on a more suiting
name
* The example with Bastien as the person responsible for
internationalization, yet only being a "developer" with no special
rights, is still not addressed.
  OTOH such a thing probably won't apply to many cases. Maybe it's
fine to simply make him a member too, with a "*" saying this only
applies to internationalization. We effectively make that exception in
practice anyway - why not say so on paper?

On Fri, Nov 8, 2019 at 8:16 PM Dalai Felinto <dfelinto at gmail.com> wrote:
>
> Hi Julian,
>
>
> 1)  "The term "member" is misleading and doesn't fit the intended role."
>
> It is a term. If wording is getting on the way we can rename it. A member
> is anyone that can be tagged in an issue and expected to be around for
> fixing bugs, patch reviews, design discussions. Regardless of being a sole
> artist or a sole software developer.
>
> This is one of the things that motivated these changes  Campbell needed a
> way to get hold of the developer and users involved in the modeling module,
> and yet the project member list did not reflect people he could actually
> contact.
>
> In the recent past I also had developers bringing up to me that they were
> tagging module members and would get no reply. For me this is where we can
> draw the line.
>
>
> 2) "(...) a single person on top of each module."
>
> It helps to have a contact point. Someone willing to take some more
> responsibility and help keeping the module page updated, lead the roadmap
> discussions, look at a patch from the design perspective and be able to
> sign off on that or to know who else to bring on board, someone to organize
> the module meetings.
>
> Having a single person as a contact point in no way makes her the sole
> decision-maker. And the fact that we are even having this discussion is a
> bit alarming. Maybe the issue is naming again?
>
>
> 3)  The same applies to my role by the way. On paper I'm also "just a
> contributor" (...)
>
> You are a module member in all but paper. Someone else in the same
> situation: Pablo Dobarro. This is why I asked you both to rectify the
> situation by taking the role of module member, and get wiki and module
> members list updated.
>
>
> > Most importantly however, happy birthday Dalai :)
> Thanks :)
>
> Regards,
> Dalai
>
> Em sex., 8 de nov. de 2019 às 10:20, Julian Eisel <eiseljulian at gmail.com>
> escreveu:
>
> > Hi,
> >
> > although I definitely do support evaluating and improving the module
> > structure, I'm not sure if the outcome really makes things better :)
> > Sorry for the wall of text. But this is a defining topic which should
> > be handled thoughfully.
> >
> > The term "member" is misleading and doesn't fit the intended role
> > IMHO. It is a loose word, I'd say everybody who does regular
> > contributions can be considered a member. And technically everybody
> > listed in the module team description is a member.
> > There must be some better term for this - Module-leads?
> > Lead-maintainers? Vice-owners? ...
> >
> > I also find it concerning that we now put a single person on top of
> > each module. William is now the sole UI module owner - does that mean
> > he can overrule any decision, effectively making him the benevolent
> > dictator for the UI? That would be horrible! ;) Not because it's
> > William, I'd say the same for any other person (including myself).
> > Non-trivial day-to-day decisions should be made based on consensus,
> > not because of one person's opinion. We should seek consensus if there
> > is none; if that fails we can still have a vote within the team.
> > Should that still not help, there are the Blender admins and
> > eventually Ton to consult.
> > What makes you think there's a need for such an exclusive role on a
> > per module level?
> >
> > Then there is the weird role of module "developers". The description
> > says these are active contributors of a module. At which point is a
> > contributor active enough to be put on this list? The threshold seems
> > to be chosen rather arbitrary on a case by case basis.
> > And what is the purpose of this category really? It feels like just a
> > list for credits and contact persons. There is some value in having
> > such a list, but besides the listed people don't have any decision
> > making power. That doesn't reflect our practical needs however.
> > Take the internationalization project as an example. The person to
> > contact and make decisions here has always been Bastien. Judging from
> > the modules page, he's merely an active contributor with no notable
> > decision making rights though.
> > The same applies to my role by the way. On paper I'm also "just a
> > contributor", but that doesn't really reflect what actual role I play
> > in day-to-day UI team business. I don't ask for more power but for a
> > more needs-oriented/practical module structure.
> >
> > Most importantly however, happy birthday Dalai :)
> >
> > Cheers,
> > - Julian -
> >
> > On Fri, Nov 8, 2019 at 5:11 AM Dalai Felinto <dfelinto at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Another change on the way. Based on feedback from Campbell as well as the
> > > development team at the Blender Institute I would like to simplify a bit
> > > the structure our module structure:
> > >
> > > 1) Module coordinator → module owner.
> > > 2) Module owner → module member (and not include the module owner on it).
> > > 3) Assign module page to module coordinator.
> > > 4) Cleanup the project page (no need to mention any developer).
> > > 5) Remove the module members not listed as members in the wiki.
> > > 6) Find more non-developer module members.
> > >
> > > This way we have a reference point for each module (owner), while all the
> > > members can be visible for the projects in developer.blender.org (as
> > well
> > > as the wiki). This also reduces the amount of redundancy, helping to keep
> > > the wiki and developer.blender.org in sync.
> > >
> > > If the module owners and members need help finding artists stakeholders
> > > (point 6) poke me in particular (or write a public message in
> > > bf-committers) and we can try to find people that demonstrated interested
> > > in the past. Most modules clearly lack non-developer members.
> > >
> > > In fact I had to remove quite a few (in particular in the User Interface
> > > Module) to match the wiki. If I made a mistake please contact me or your
> > > corresponding module owner to have your contact up again in the wiki and
> > > developer.blender.org.
> > >
> > > Thanks for your comprehension,
> > > Dalai
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > https://lists.blender.org/mailman/listinfo/bf-committers
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list