Hi Narayan, I just finished reading the thread, and I'd like to come back to your mail. You've stated some project and development fundamentals, and that is something I'm very interested in ... how to tailer such methods and tools. And if I got it right, you as well :-)
Am Mittwoch, den 19.01.2011, 14:52 +0530 schrieb Narayan Aras: > Hi Italo, > > > Date: Tue, 18 Jan 2011 13:13:55 +0100 > > From: italo.vign...@gmail.com > > To: website@libreoffice.org > > Subject: Re: [libreoffice-website] [Drupal] The road ahead and missed > > opportunities > > [...] > BTW I have consistently maintained that mail lists are not suitable to > capture such matters. > There are easy solutions available. But SC is not interested. [...] Mmh, maybe I've missed that - but what would be one of the solutions you have in mind? One of the specifics of the settled parts of the community is, that many of the activities are spread among different places. Much of the work is even done offline, so the mailing list - although having some drawbacks - has always been a rather reliable connection between all the people. What I've experienced in the last years was, that the most challenges are in the communities that start to grow - for example in countries where education is still a challenge (and LibreOffice a key). Less reliable power connections, almost no Internet connection, ... On the other hand, LibreOffice has some real chances to grow there and improve people's life. Okay, just an example - but such constraints make it really interesting to identify most requirements, because the workflows are "dictated" by external circumstances. The magic is and will be, to bring that together. To come back to the previous question, I think that mailing list have their drawbacks - absolutely agreed. But I think they are one valid part of the solution. > > I am not a web site expert, but I am a member of the SC and in addition > > I am the one coordinating marketing (you might complain about this, but > > I got the trust of the founders based on seven years of activity inside > > the OOo community). In order to approve an approach, you have to "sell" > > it before even starting to work at it. > > Well, note that the mail lists cannot distinguish between "approved" tasks, > "unautorized" tasks and "new proposals". > Further, within an approved project, you cannot control each and every aspect > that is proposed. > This is an inherent weakness of mail list. Mmmh, is that tied to mailing list? When thinking about what I've experienced so far, it is easy to "break" any tool :-) The more people participate, the earlier it will happen. Oh, "more people", seems a reasonable thought ... Referring to what Italo said, I'm sure he didn't mean to formally "approve" something - in this context. Your postings reveal, at least I think so, that you are very familiar with the business world. If you set up a project, it is usually proposed to (how to say that in English?) provide acceptance criteria / project agreement between the supplier and customer (CMMI *g*). Having that, it is easy for both parties to verify the project delivery ... and to roll-out the newly developed system/software/service. The agreement helps (among requirements, goals, scope ... you know such stuff) to plan your project in advance, to calculate the costs, allocate resources. I think that works very very well for such organizations. What I'm curious about, whether this works within an open-source project. With such a huge (and incredibly interesting) task like project infrastructure, you have hundreds of individual contributors ... whom to ask whether the system fits to their needs? Or, how can they tell if not? What Italo referred to, is to get some buy-in (interest / demand / ...) in advance - within the community. If they like it, a system will be used ... so think of it like the preparation of the "social" roll-out plan. I think those who took part in any larger volunteer community, can state some "CMMI" like essentials to bring ideas forward. It's different to the business world. Okay, this was a bit oversimplified - this is also true for large organizations (most large IT projects fail, because users are resistant against the changes). But let's keep the community topic alive :-) [...] > That is at the root of all trouble: > 1. SC does not make/approve/drive projects with WBS. I think the SC drives the things that are vital for getting the foundation done - this is the basis of many upcoming activities (driven by the community). Although you might think of a very detailed WBS, here is what currently is used ... http://wiki.documentfoundation.org/TDF/Work_Items And, are you sure that initiating LibreOffice, providing build and deployment infrastructure, identifying trademarks, managing artwork, setting up the initial infrastructure, communicating with the press, inviting hundreds of people to join, managing volunteer availability ... was done without WBS and thoughtful project planning? ;-) [...] > Look, pedigree is useful in a dog show, not here. > I think we should focus on merit of an idea, not WHO proposed it. That's true. But (as far as I understand) the idea is an idea, unless it is turned into practice. And sometimes it helps to know some "pedigree" to make sure that nothing is missed and the idea has potential. Like you find in larger cooperations ... so called "Expert Organizations" with people who can provide advice. Like Italo did numerous times for me. By the way, that reminds me that I'd find it very helpful if we could do some introduction - I'm curious with whom I speak with. What do you (all) think? Would that be okay for you? > In any case, most volunteers are not vying to become SC-members. > At least those people should be excused for not advertising their lineage. > > > I am very interested in understanding: > > > > 1. Why you decided to create "roles" (it might be a silly question, but > > when you deal with people different from you I have learned that there > > are not silly questions) > > @the word "roles" > No this is a good question, and I am sure everyone else on the SC > knows the answer already, because they are from software development > community (you are the only outsider! :) ) Oh, there is much more variance within the community :-) > The original word I used was "stakeholder" which means anyone who has > an interest in the product. This term goes beyond the "users". Yep. > But later someone suggested that a given team can act as multiple types of > stakeholders. > So I changed the term to "role" to avoid confusion. > The idea is that any person/team can play multiple roles; and there may be > churn in how these roles are played. > The website should be flexible enough so that its interface changes to > accommodate any role-mix. Just to get the picture ... you planned for different roles within given processes / context / domain. Or, did you adapt some of the processes to make them more streamlined? I ask, because it might easily happen that you identify "translator", but this guy will work in different contexts / or different constraint sets. That would require some processes to be defined with different kinds of (process) interfaces ... > ** > @Is this a standard concept? > Yes. Refer to CMMI-DEV 1.3 (www.sei.cmu.edu/reports/10tr033.pdf) > pp.337-352, 385-404. > > A MUCH simplified model is as follows: > For any software, we start with identifying the stakeholders. > Then we find the specific requirements of each stakeholder (called > "elicitation"). > Then we check if there are any conflicting requirements and find a balance > (trade off). > > Later, during design process, we decide which part of the product will > satisfy which of these needs. > > For website design, there are special techniques: > We classify users in "demography" (race, age, sex, etc.) because their habits > may be different. > Then we model typical customers through "personas". > This lets us design the perfect website that exactly meets the needs of all > users. > **** Cool, somebody who is keen to say "personas" ... we should talk! :-) (see [1]) > All this does not need any selling, because any professional software > developer will follow this. > This is part of the profession. So, how many software developers are part of this community? And how much does the project rely on the work done by non-developers? > > 2. How you decided to define these "roles" > > Most roles were from standard software development team structure. > Refer to PMBOK (project Management Body of Knowledge) for details. > Again, all people from software development community are supposed to know > this. Okay, so now I'm interested in how to "match" these roles to the ones to be found in the community ... you stated the standard development team structure. It is true that there is some structure and (let's call it "best practices", at least - CMMI is a collection) best practices. But in contrast to thoroughly planned projects: involvement and interest varies, knowledge varies, hard-to-predict schedules (mostly) ... you also don't have "competence management", so its hard to rely on given experience/knowledge. For example, people within the community evolve ... a good example had been stated by Italo. So - what I see - it's great to see some structure when addressing these questions, but please plan for some degree of freedom :-) > > 3. How you got to the number of "23 roles" (my perception is that 23 > > might be way too many, but I might be wrong) > > Well, this is a large project, with a large number of stakeholders. > I cannot remove some of them to bring down the number. > > Although some of the roles can be combined, their specific needs cannot be > ignored. > Each role-player would be using the website for his daily/weekly/monthly > tasks. > All this work is interrelated: Someone's output is used by someone else. > So we cannot skip roles. Thinking ... You are right, if you plan something like infrastructure, it is good to somehow consider the different needs. On the other hand, it is unlikely to please everyone in the very first step ... and since many of the changes will affect a large part of the community (and many essential processes), focusing on a few roles might make sense. Exchanging documents / data may then be done (manually) via interfaces (exporting files, ...). This would - from my point-of-view - have some benefits: * You can optimize the processes / tools for one topic (first) * All other processes keep unchanged * If it runs for one target group, you'll get the "buy in" of others more easily Still thinking ... you talked about the different tasks and the interrelation of work. It might sound stupid, but many people here really like to be with each other. Talking, doing something together - in my impression, they accept some cumbersome communication media / less efficient tools, because they simply enjoy taking part. So one of the requirements is to keep the balance between "efficiency" and "enjoyment". Something like: The journey is the reward. I've talked to a lot of people, and its really fascinating what different kinds of motivation they do have ... [...] > > I think that once these five questions (maybe silly ones, as I said) get > > an answer and are fully understood by the community (the founders and > > the SC are supposed to be the first community representatives even if > > sometimes their behaviour might look different, but everyone should > > remember that we are all individuals with our own pros and cons, and our > > specific way of expressing ourselves, independently from our role) then > > we might have a better understanding of the beauties and the advantages > > of a different (and improved) web site). > > > > I think that the main fault of everyone in this specific domain of the > > web site (including SC members) was to overlook the web site problem and > > leave it unmanaged. > > > > I look forward to get the answer to my questions. Ciao, Italo > > Thanks for trying to bring truce, but all software development guys already > know what we mean. > The idea is neither new not does it need to be sold. A serious question, are you still sure about that? Oh, and "truce" is a good point thanks Italo, and also you Narayan! Good night, everyone! (Or day/midday/...) Cheers, Christoph [1] http://uxopenofficeorg.blogspot.com/2008/06/introducing-our-new-member-jennifer.html -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://listarchives.libreoffice.org/www/website/ *** All posts to this list are publicly archived for eternity ***