Hi, I'm going to split my critique of the Documentation into two sections. I first want to address what I feel are some factual inaccuracies about how Factory/this distribution is currently developed. I will provide commentary to explain why I believe the current documentation to be wrong, which is why I'm writing this email here and not making changes direct to the wiki. Secondly, I want to provide my suggestions to address a number of painpoints this documentation has brought up. There will be some overlap, but I'll want to make it clear I see two separate sets of issues here that need to be addressed - We need to make sure the current documentation is an accurate reflection of the facts, and then we need to decide how we want to develop stuff moving forward So, starting with my proposed corrections of the document: https://en.opensuse.org/openSUSE:Development_Process
The goal of this document is to:
Serve as main reference to the existing documentation around the process. Provide the big picture of the process to those potentially interested in joining. Help us to detect areas for improvements. Explain the process to SUSE employees.
The wording of this is not helpful. I've been part of the project for years, and for the bulk of them, we've worked very hard to dispel the myth that SUSE are 'in charge' of the openSUSE project. They're our biggest sponsor, and a hugely important part of this community, but are not the only significant part. In fact, we now have hard data showing that SUSE employees are consistently in the minority of contributors to Factory, and there hasn't been a weekly 'Top 10 contributors to Factory' table that wasn't stuffed with 'non-SUSE contributors', often taking the #1 and #2 spots, sometimes both. Should we use this data to engage in some pointless measuring exercise and spiral into a dangerous debate of the 'SUSE vs non-SUSE contributions'? Or should we emphasis the established Guiding Principles of the project and value *all* contributions equally regardless where they come from? I understand the openSUSE team @ SUSE was motiviated into doing this work to address the concern that SUSE employees working on openSUSE need to know the lay of the land - but a SUSE employee is no different from Joe or Jane Bloggs sitting who knows where working on their first patch for openSUSE in their spare time. Our documentation should reflect that. I also can't help but feel it's a bit of a shame that it took the business needs of SUSE to motiviate this Documentation exercise (which I do think is worthwhile) - I suppose in an idyllic situation, the motivation should have been there to produce this document for everyone, anyhow. So with that all said, I strongly believe we should redefine the goal of this document as follows "The goal of this document is to: Serve as main reference to the existing documentation around the process. Provide the big picture of the process to the existing community and those new to it Help us to detect areas for improvements." "those new to it" includes those SUSE employees who will be joining us in the coming weeks, but doesn't single them out for any special treatment or favour. Onto the next session I feel is inaccurate/incomplete. I want to talk about the section that starts
Roadmap and Feature Planning. The Release Manager creates the initial roadmap [1] [2] [3] .....
This isn't wholly inaccurate obviously - Coolo does set the timetables and our contributors do define what features and functions will end up in the next release. But there is no mention at all of the opensuse-factory mailinglist, home of the debates between our developers who suggest new features, and the place where the discussions inform and decidee whether or not those features are included in the distribution . Just look at the recent discussions about btrfs and MATE to see how Feature Planning is really carried out in the distribution - a contributor (be they someone from SUSE labs or who-knows-where) comes up with an idea/feature/package set they want to add to the distribution, and our entire active contributor base gets an opportunity to discuss, evaluate, improve, and ultimately decide and execute that decision. The Release Manager of course has final say, but the reality is a lot more nuanced than the picture painted in the current documentation. The implication that 'individual teams decide amung themselves' is false. We're a community that collaboratively develops this distribution through an organic distributed discussion and decision process, our documentation should reflect that. I also question the accuracy of suggesting openFATE plays a major role in the Feature Planning process. openFATE does a good job of collecting the desires of much of our userbase, but it is my experience that in most cases the new features we introduce into the distribution are a function of 'what is possible by building on newly available tech from upstream' rather than 'lets create something brand spanking new in order to clear the openFATE request'. Whether or not this is a good thing or a bad thing, whether or not this how we should do things, is a debate the community might want to have, but until we do, I wouldn't imply that openFATE has any major part to play in the Roadmap of openSUSE, that's just not my experience. Next Topic - Product Manager
Product Manager and Release Manager decide that a new release cycle can begin
This thread has seen a revelation that was a surprise to many (myself included) that there is a SUSE employed 'openSUSE Product Manager' - a title and role which I was under the impression was dissolved some time ago.. a fact which also seems to be confirmed by statements made in this thread. Given the situation seems ambigous or contradictory, I'd suggest the situation is either clarified, or mention of the 'Product Manager' from the documentation should be removed in the name of ensuring the document provides a clear lay of the land. Next Topic - Testing A Topic near and dear to my heart. It saddens me that the current diagram and documentation makes no mention of those people testing Factory (and/or Factory+Devel repos of their choice) and providing continual QA feedback before the Beta release process. This is an area we want to encorage more people to do, and yet right now their valued contributions are totally ignored by this version of the documentation. Not good. Let's fix that. Now with that over, I want to bring up a few potential 'areas for improvement' that this document shines a light on Product Manager As I mentioned above, there seems to be confusion here whether this role currently exists in the project or not, but if we have one, and their role is as defined in this documentation ("review the Roadmap"), I think it is a terrible situation and a significant retrograde step back for the project. I've already laid out the reality (as I see it) of how our Roadmap comes together, and so I see a SUSE-employeed overseer of the roadmap as either an unwelcome controlling influence on the project, or role that doesn't have much to contribute - with an open development process, and open discussons deciding our features going forward, isn't the job of the Product Manager reduced to just watching the opensuse-project mailinglist and nodding as 'those who do, decide'? I am especially concerned with the suggestion that this role is seen as a 'SUSE role, not an openSUSE role'. Whatever the role, whatever the level, whoever pays their paycheck, those working on this project should see themselves openSUSE contributors, caring for and working for the benefit of openSUSE. Period. Release Manager I worry that our beloved Release Manager, Coolo, is both a single-point-of-awesome and a single-point-of-failure. This documentation paints them as the sole arbiter of the Release schedule, and the only one doing a huge amount of the release work, image building, signatures, syncing, etc. It's exceptional work, but I worry that if something were to take Coolo away from us, we'd stall as a project. To me it seems natural that 'Factory Maintainers' could be involved in almost all, if not all, of the Release Managers tasks. This probably wouldn't be in a 'lead' capacity, but would at least ensure that more people knew how Coolo does his magic, rather than just seeing it as magic. This is not just to give 'non-SUSE contributors' an opportunity to be involved in this very important work, but to ensure that our projects Bus Factor is greater than 1 QA I think it's safe to say, the current amount of testing of Factory before a Beta release is 'less than we would like', how else could it have been forgotten entirely in this version of the draft? While openQA is a wonderful tool, automated testing has its limits and typically finds only the issues its been taught to find. Human testing on the other hand finds 'real world' issues, the ones that really matter to our users, and the ones that really help the quality of the release. I'd like to see the importance of Factory testing encoraged more, I think there are more people out there willing to test Factory, but don't know how to or are put off by our less than ideal bug entry options in Bugzilla. Maybe we should fix that (*hint* http://www.github.com/tdf/www-bugassistant) Lets make ongoing humanQA as much a part of the process as openQA, which hopefully should lead to smoother Public tests and a better polished product at the end. There, my 2c... thanks for reading. On 20 September 2013 21:22, Robert Schweikert <rjschwei@suse.com> wrote:
Hi,
On 09/20/2013 09:44 AM, agustin benito bethencourt wrote:
Hi,
Can you point me to concrete examples on the documentation that
affect that fight?
We didn't have any intention to go against it.
The fact that there IS a document addressing SUSE Employees
specifically makes them different to the broaded openSUSE community.
That's the underlying issue here.
The document has four goals. There are no further intentions beyond them. They are better described in our team blog post about this topic[1].
Let quote them for those who haven read the document:
"The goal of this document is to:
* Serve as main reference to the existing documentation around the process. * Provide the big picture of the process to those potentially interested in joining. * Help us to detect areas for improvements. * Explain the process to SUSE employees. "
I think that the first three justify the document by itself. We could have skipped the fourth one in order to avoid controversy, but we think it would be unfair and, at some point, it would be noticeable anyway.
Why do you think that not singling out SUSE employees is unfair?
Is it unfair because they have a special status or expect a special status?
Why would you think it is/will be noticeable at some point if SUSE employees are not singled out? If SUSE employees are treated equally within the community and documentation instead of being singled out, what is noticeable about that?
There are two things to be considered: 1.) We have a history of perception, and perception is reality, that SUSE people are special. This makes everyone a bit sensitive on this subject. Therefore, mentioning SUSE employees as special in any documentation will open a wound that is in every-ones memory. Maybe for the next generation of contributors that will not be an issue.
2.) Singling out any specific group over another in a document when no value is added by this specific mention makes the singled out group special. That's a feature of the language and our common understanding of the language.
A lot of transparency helped in achieving that, opening channels
and there. And the 'mood' did settle in for that. Please, let's not
spoil that and become a corporation vs 'volunteer community' again.
I think that having a documents where the current process is
explained is an exercise
of transparency, which is the first step for delegating and sharing
responsibilities that
are still within SUSE.
That is appreciated. But then, as Robert also pointed out, you have to
make sure that the document mentions things that are relevant to the
project, and now that seems relevant for how SUSE wants the project to
be (Product Manager role for example; as perfectly outlined by Robert,
does not fit the current project)
SUSE decided to remove the the openSUSE Product Manager title. AJ was the last openSUSE product manager at SUSE.
But there are some tasks/responsibilities that this role had assigned that still make sense internally. Since many of the tasks around the Release are done in SUSE, the role still have influence in some internal areas. This is why you see this role in the document.
Based on the responses, not only by me, it is reasonably obvious that a number of people were surprised that the role still existed. There was no announcement at the time when AJ no longer filled the role that any remaining responsibilities/tasks were picked up by anyone else, at least as far as I recall.
Again, we have described the current Development Process, not the process we want to have.
There is no problem with attempting to document the process as it is. However, the document preliminaries do not state this. Based on the preliminaries, it is not reasonably obvious if this process document reflects, the past, present, or future. Considering that a number of people had no idea the Product Manager role still existed and that something completely new, EVTX, showed up it is perfectly reasonable to expect for people to think that the document reflects the future.
Based on responses I would say that EVTX and the definition of the process via EVTX is new.
We are trying to let you know how the process work in areas that probably were dark before.
That's great, but, and this may be that I am not high enough on the contributor food chain, I had no idea there was a process that determines the new features, as described in T1.3, for the next release. It was at least my impression that the new features basically just show up based on the work maintainers do throughout the release cycle, rather than creating a pre-determined plan. This goes back to planned vs organic growth and development.
I assume that part of this information might not be pleasant for some, but it is how we are currently working.
Just looking at the "Determine the new features" task (T1.3) I question whether this is how we are working. But again, I may not be aware of this process because devel project maintainers may get together at some point prior to the release and complete this task, I just never heard of such a meeting or discussion.
Are there things in the process we don't like? Let's change them.
"Shooting at the
journalists" for documenting them is not part of the solution.
I don't think anybody here is on a personal vendetta against you. You
published a document and asked for feedback. Things pointed out are
that the document implies too much 'SUSE being special' That's all.
And in non of the feedback was there any attack on the messenger. The feedback was simply based on the document and if someone else would have written the feedback would most likely have been exactly the same.
We have tried to be very accurate,
That's appreciated.
but we are not the referee, we are players here. This is why we are asking for feedback. And the more concrete is that feedback, the easier for us to improve the document.
Well I was very concrete I believe, let me pull some of the very concrete items from my original mail back into this discussion. If this is not concrete please iterate what other information is needed to be more concrete:
Select from previous feedback mail in no particular order:
""" The entry for the "Review Process" matches T3.4, but does not match the exit condition X3.1 w.r.t. the role. """
""" It appears that in "Factory Integration" the tasks for feeding back changes from "The Factory Maintainer decides to fix an issue inside Factory" to the devel project are missing. """
""" What is WBS? """
If you could please be so kind and re-read my original feedback and let me know where the feedback is not concrete enough to improve the document that would be great, I'll be more than happy to clarify.
In summary: It is great that an effort is being undertaken to document process that are being followed. Clarity in communication whether this documentation describes past, present, or future is missing in https://en.opensuse.org/openSUSE:Development_Process. Additionally as described the document, based on common knowledge, may imply that it describes some future desired direction. Concrete items from a previous feedback e-mail were not addressed in this e-mail thread to this point.
Later, Robert
-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org