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