Hi Mirek, On Thu, Jun 19, 2014 at 05:56:35PM +0200, Mirek M. wrote: > Astron told me that the idea to have positions within the design team was > not well-received and that I should discuss it with you. What do you find > problematic about having positions within the team? > > To be clear, leads would be there to make sure that things get done, that > the process by which they get done produces the best results, and to > resolve controversial issues if they arise.
as others have aleady expressed, electing such titles and granting them on extended timeframes has historically proven to be a hazard. I believe in "With great power comes great responsibility", or corollary: power should always be based on current resposibilities. To give you an example, Ubuntu has the concept of a patch pilot: https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch_Pilots whos prime responsibility is to welcome newcomers over a certain timeframe (a day/a week). There is a natural authority derived from those doing duty on those, without any need for granting titles or elections. It also usually keeps those most involved with growing and progressing the team by doing onboarding work -- which admittedly often is not the most attractive task -- in high regard and prevents "title-envy" as everyone knows the work attached to the authority. Now, I dont know if and how that can be translated to the design team. One (likely stupid) idea would be to have an email alias for onboarding newcomers and anyone decently skilled(*) can join that alias and help newcomers asking questions to it. In general, if things are not completely broken in the project, those who do the most work there in helping others should naturally grow authority in the design project. Then again, the same thing should work on a mailing list -- but a onboarding mail alias _might_ make more obvious who is doing most in onboarding newcomers and who is mostly following his or her own agenda(**). Just my two eurocents -- I admittedly dont have to deep an insight into the design team structure. Best, Bjoern (*) use common sense here, like for direct commit access for developers (**) which might be perfectly fine, but isnt the best prerequisite for leadership work -- To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/board-discuss/ All messages sent to this list will be publicly archived and cannot be deleted
