Am Mittwoch, 18. September 2013, 21:06:55 schrieb Per Jessen:

Agustin Benito Bethencourt wrote:

...

Hi,

if you get bored of testing 13.1 Beta, do not hesitate in providing us feedback :-)

Link: https://en.opensuse.org/openSUSE:Development_Process

Two immediate questions:

a) what is ETVX and what's it doing here? ETVX is a software process model and here used to describe the 'openSUSE Development and Integration Process'.

We _E_nter each process with a defined state, perform different _T_asks, apply _V_erification for QA and e_X_it the process with in a desired state. Thus, ETVX.

b) who is the openSUSE product manager? (I wasn't aware we had one). I'd guess coolo, as he handles Factory -> Beta/Mn/Goldmaster.

Can someone take a look at https://en.opensuse.org/Portal:Teams -> People of openSUSE (Who is who in openSUSE)[1] and create an initial page?

/Per

[1] https://en.opensuse.org/openSUSE:People -- Aeneas Jaißle » e: aj@ajaissle.de Sent using Kontact and Kolab on openSUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Agustin Benito Bethencourt wrote:

Hi,

On Wednesday, September 18, 2013 09:06:55 PM Per Jessen wrote:

...

Agustin Benito Bethencourt wrote:

...

Hi,

if you get bored of testing 13.1 Beta, do not hesitate in providing us feedback :-)

Link: https://en.opensuse.org/openSUSE:Development_Process

Two immediate questions:

a) what is ETVX and what's it doing here?

Aeneas explained what it is. What's doing here? We decided to use a methodology and this one is a simple one, so it was easy to learn and to use.

Thanks. I know what ETVX is, but I wasn't aware we were using/following it.

...

b) who is the openSUSE product manager? (I wasn't aware we had one).

AJ has been traditionally playing that role. When he moved to other duties, I took over. It is a SUSE role, not an openSUSE one.

That's why I asked - I was surprised to see we had an openSUSE product manager. -- Per Jessen, Zürich (0.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 09/18/2013 12:05 PM, Agustin Benito Bethencourt wrote:

Hi,

if you get bored of testing 13.1 Beta, do not hesitate in providing us feedback :-)

Link: https://en.opensuse.org/openSUSE:Development_Process

Hmm, what makes SUSE employees special? Are we more dense than other contributors or "those potentially interested in joining" that a document has to be created that is intended to "Explain the process to SUSE employees" ? SUSE employees that are already contributing should be involved in this discussion and provide feedback like everyone else, and those that are not, should not be singled out or receive special status from "those potentially interested in joining." If the language in the documentation suggests that there is a higher level of "citizenship" to be obtained by being a SUSE employee than we have wasted 5 years of effort in overcoming the perception that such a higher level of citizenship exists. It is nice that you decided to use EVTX, however, can you please point me to the thread on the factory mailing list where the pros and cons of this versus other processes was discussed? I must have missed the discussion as I do not recall the thread and taking a cursory look at the factory archives didn't make it immediately obvious which thread I should read. Thanks. What is WBS? Feedback should be given on a list, as is being done now. Having a private e-mail in the document encourages private feedback and thus the exclusion of the community, that's bad practice. The EVTX plan shows a roadmap and feature plan created by a Product Manager. As I pointed out in a previous reply to this thread, this is "directed development". Today the project and distribution grow organically, people implement the features they are interested in. If we want to change the model to directed development that will require a discussion in the developer community. The SUSE team is certainly free to follow a directed development model, however, without an open discussion I cannot see how the rest of the development community can be expected to buy into such a model. I for one am opposed to a directed development approach for the entire distribution. Further, the concept is flawed, as we have a large number of package maintainers that are not intimately involved with the upstream development project. Therefore, it is not possible for those maintainers to "Determine the new features". Whatever upstream produces, that's what we get. Even for projects where we are intimately involved, such as the kernel, pre-determining features is not possible. No one knows ahead of time what features will be in the kernel at what time, thus the exit condition of "Roadmap and Feature Planning" cannot be met. Unless we resign to making a plan based on things that are already released upstream (than we can determine the features), which implies that we will always ship "old" stuff. In case of 13.1 that would imply we'd be releasing with the 3.10 or even the 3.9 kernel (depending on timing of the planning process) instead of 3.11 and who wants a community distribution with an old kernel at release time? As far as package development and maintainership is concerned, a package maintainer needs to be able to decide whether her/his package goes to Factory or not, this is not the job/role of the devel project maintainer (T3.4). Lets look at an example. If I maintain package A in a devel project, but I do not want it in Factory than I should be able to have this arrangement. If the devel project maintainer decides that the package should be in Factory, than the devel project maintainer assigns additional work/responsibility to me, something I as a package maintainer will not be very fond off. Thus, the devel project maintainer that makes such decisions has to become co-maintainer of the package in question to take on the additional responsibility that comes along with having a package in Factory. With this step, i.e. becoming co-maintainer the package maintainer exercisers the decision about whether or not the package should be in Factory. Also x3.1 and T3.4 appear to be in contradiction. 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. Thanks for doing the work. However, not having had a discussion if we, as a whole, should have a directed development process it appears a bit pre-mature to have one documented. Of course as I mentioned above the SUSE team is always free to follow a directed development process for the work they do. We just have to sort out the implications/consequences of having part of the community follow a directed process while another part does not follow a directed process. How do we handle the cases where a community contributor not following the directed process submits a feature that is not in the directed plan. Will the feature(s) be considered and accepted, pretty much as it is today, or will they be rejected because it wasn't planned? Well a bit more than $0.02 worth. 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

Hi, we have draw a picture of how the process works right now. We have not defined how the process should look like or how we want it to be. As any of you can see in the documentation (both, the development process and the release process) there are many "hidden tasks" that are still done within SUSE. In fact, many more than even I thought a year ago. The first step has been documenting them and make them public. In the Release process we have opened already several of them. We will continue in that direction. The same applies to the Development process. So I take these complains as points of improvements for the future. The goal of my team is keep opening the process. We need more people to take responsibilities though. There we have a challenge. On Thursday 19 September 2013 21:33:50 Dimstar / Dominique Leuenberger wrote:

On Don, 2013-09-19 at 12:03 -0400, Robert Schweikert wrote:

...

On 09/18/2013 12:05 PM, Agustin Benito Bethencourt wrote:

...

Hi,

if you get bored of testing 13.1 Beta, do not hesitate in providing us feedback :-)

Link: https://en.opensuse.org/openSUSE:Development_Process

Hmm, what makes SUSE employees special? Are we more dense than other contributors or "those potentially interested in joining" that a document has to be created that is intended to "Explain the process to

SUSE employees" ?

AMEN to that!

...

SUSE employees that are already contributing should be involved in this discussion and provide feedback like everyone else, and those that are not, should not be singled out or receive special status from "those potentially interested in joining." If the language in the documentation suggests that there is a higher level of "citizenship" to be obtained by being a SUSE employee than we have wasted 5 years of effort in overcoming the perception that such a higher level of citizenship exists.

And a Halleluja! We fought hard to have the perception that SUSE is 'a regular' contributor to the distribution. We kept on putting posts straight trying to imply different. A lot of transparency helped in achieving that, opening channels here and there. And the 'mood' did settle in for that. Please, let's not spoil that and become a corporation vs 'volunteer community' again.

Dominique -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com

Hi, On Thursday 19 September 2013 21:33:50 Dimstar / Dominique Leuenberger wrote:

On Don, 2013-09-19 at 12:03 -0400, Robert Schweikert wrote:

...

On 09/18/2013 12:05 PM, Agustin Benito Bethencourt wrote:

...

Hi,

if you get bored of testing 13.1 Beta, do not hesitate in providing us feedback :-)

Link: https://en.opensuse.org/openSUSE:Development_Process

Hmm, what makes SUSE employees special? Are we more dense than other contributors or "those potentially interested in joining" that a document has to be created that is intended to "Explain the process to

SUSE employees" ?

AMEN to that!

Since some people from SUSE that traditionally do not work in factory is joining us, we wanted them to have a document that explained to them the differences between the SLE dev. process and the openSUSE dev process. We had that in mind when we made the document. I think it will be useful to help them integrate faster and without friction. Sometimes changing the way you work in a very short period of time is not easy. We want this process to go smooth.

...

SUSE employees that are already contributing should be involved in this discussion and provide feedback like everyone else, and those that are not, should not be singled out or receive special status from "those potentially interested in joining." If the language in the documentation suggests that there is a higher level of "citizenship" to be obtained by being a SUSE employee than we have wasted 5 years of effort in overcoming the perception that such a higher level of citizenship exists.

And a Halleluja! We fought hard to have the perception that SUSE is 'a regular' contributor to the distribution. We kept on putting posts straight trying to imply different.

Can you point me to concrete examples on the documentation that affect that fight? We didn't have any intention to go against it.

A lot of transparency helped in achieving that, opening channels here 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. 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.

Dominique

Saludos -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com

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.

...

...

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. Again, we have described the current Development Process, not the process we want to have. We are trying to let you know how the process work in areas that probably were dark before. I assume that part of this information might not be pleasant for some, but it is how we are currently working.

...

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.

We have tried to be very accurate, 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. And no, I do not take these criticisms as personal. If that is what it seemed from my comment, I didn't express myself correctly.

Dominique

[1] http://lizards.opensuse.org/2013/09/18/documenting-the-opensuse-development-... Saludos -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com

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

Hi, I will integrate these feedback into the wiki before we can remove the Draft status. My work here is to document what is really happening in the development process. So this document is descriptive, not prescriptive. I want to discuss the changes that I think that we need to make in the documentation: * Goal of the documentation [Remove Explain the process to SUSE employees. ] """ 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. """ * openSUSE Dev. and Int. Process High Level Description [Reference T1.3 for a better explanation of the process. Reference the mailing list. Downgrade openFATE as a documentation tool] """ - Roadmap and Feature Planning. The Release Manager creates the initial roadmap [1] [2] [3] by putting in the number of milestones, betas and release candidates that need to be released for the distribution. The schedule is adjusted taking into consideration vacations and other constraints described in the Roadmap Process. In parallel, developers from the community will decide a set of technical goals for the distribution based on the projected release and freeze dates [4] [5], using the mailing list and documenting these features in openFATE [6][7] or in a dedicated wiki page per project (see T1.3 for a further description about how the features are decided). The feature freezes are scheduled as part of this task. """ * Product Manager Looks like that there is some agreement that this role is a SUSE role, and that the name is not precise enough. I propose to change this name and the description in the documentation. I can propose something like "Project Coordinator", "Project Representative", I don't know. If there is not consensus, I propose that at least we include a note in the role description that the Product Manager is not an openSUSE role, but a SUSE one * Roadmap and Feature Planning [Add more relevance to the mailing list, and less to openFATE] """ - T1.3 Determine the new features. On the mailing list (as the primary channel for discussing ideas and features) and through other community communication channels the new features expected for this release are discussed and defined. Some of those features can be documented on openFATE [6] (not widely used) or the wiki [3]. The features are decided inside the community (in this moment this is done only by a really small number of contributors) or internally in SUSE when there is a relation between SLE and openSUSE: a developer can create a feature in FATE for SLE and then add openSUSE afterward (this kind of feature is not visible outside) At this moment we do not have a strict policy on using openFATE. Some features are also decided later without planning and documentation. If the feature is implemented after the freeze calendar, and explicit approval from the Factory Maintainer is needed for the integration. """ * Devel Project Integration [Add the Package Maintainer in the decision to submit to factory] """ - T3.4 Submit to Factory. Once the Package or Project Maintainer considers the package(s) in his project good enough he/she creates a submit request for Factory. """ [Fix a contradiction in X3.1] """ - X3.1 The Package or Project Maintainer creates a submit request for Factory """ * Factory Integration Comment from Robert: 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. I think that this is T5.5. If the Factory Maintainer decides that he / she want to fix something he become a Package Developer for this moment (fix the issue, create the SR, and integrate into factory). Am I wrong here? * Public Test [Add Factory testers. Add a new reference] """ - V7.1 Test in real machine. The user (or developer) can go to software.o.o [14] to download the release and install it in the real hardware. If he / she detect a bug a new bug report is created in bugzilla [19] or / and a mail is send to the Factory mailing list. Also, many users decide to test Factory directly updating the repositories [50], without installing the released media. [50] How to install Factory http://en.opensuse.org/openSUSE:Factory_installation """ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, September 24, 2013 11:14:54 AM Alberto Planas wrote:

Hi,

I will integrate these feedback into the wiki before we can remove the Draft status. My work here is to document what is really happening in the development process. So this document is descriptive, not prescriptive.

I want to discuss the changes that I think that we need to make in the documentation:

* Goal of the documentation

[Remove Explain the process to SUSE employees. ]

""" 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. """

* openSUSE Dev. and Int. Process High Level Description

[Reference T1.3 for a better explanation of the process. Reference the mailing list. Downgrade openFATE as a documentation tool]

""" - Roadmap and Feature Planning. The Release Manager creates the initial roadmap [1] [2] [3] by putting in the number of milestones, betas and release candidates that need to be released for the distribution. The schedule is adjusted taking into consideration vacations and other constraints described in the Roadmap Process. In parallel, developers from the community will decide a set of technical goals for the distribution based on the projected release and freeze dates [4] [5], using the mailing list and documenting these features in openFATE [6][7] or in a dedicated wiki page per project (see T1.3 for a further description about how the features are decided). The feature freezes are scheduled as part of this task. """

* Product Manager

Looks like that there is some agreement that this role is a SUSE role, and that the name is not precise enough. I propose to change this name and the description in the documentation. I can propose something like "Project Coordinator", "Project Representative", I don't know.

If there is not consensus, I propose that at least we include a note in the role description that the Product Manager is not an openSUSE role, but a SUSE one

* Roadmap and Feature Planning

[Add more relevance to the mailing list, and less to openFATE]

""" - T1.3 Determine the new features. On the mailing list (as the primary channel for discussing ideas and features) and through other community communication channels the new features expected for this release are discussed and defined. Some of those features can be documented on openFATE [6] (not widely used) or the wiki [3]. The features are decided inside the community (in this moment this is done only by a really small number of contributors) or internally in SUSE when there is a relation between SLE and openSUSE: a developer can create a feature in FATE for SLE and then add openSUSE afterward (this kind of feature is not visible outside) At this moment we do not have a strict policy on using openFATE. Some features are also decided later without planning and documentation. If the feature is implemented after the freeze calendar, and explicit approval from the Factory Maintainer is needed for the integration. """

* Devel Project Integration

[Add the Package Maintainer in the decision to submit to factory]

""" - T3.4 Submit to Factory. Once the Package or Project Maintainer considers the package(s) in his project good enough he/she creates a submit request for Factory. """

[Fix a contradiction in X3.1]

""" - X3.1 The Package or Project Maintainer creates a submit request for Factory """

* Factory Integration

Comment from Robert: 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.

I think that this is T5.5. If the Factory Maintainer decides that he / she want to fix something he become a Package Developer for this moment (fix the issue, create the SR, and integrate into factory). Am I wrong here?

* Public Test

[Add Factory testers. Add a new reference]

""" - V7.1 Test in real machine. The user (or developer) can go to software.o.o [14] to download the release and install it in the real hardware. If he / she detect a bug a new bug report is created in bugzilla [19] or / and a mail is send to the Factory mailing list. Also, many users decide to test Factory directly updating the repositories [50], without installing the released media.

[50] How to install Factory http://en.opensuse.org/openSUSE:Factory_installation """

Please, check [1] and [2] to find the update in the documentation. If we have more concrete input I will integrate them this week. [1] http://en.opensuse.org/index.php?title=openSUSE%3ADevelopment_Process&diff=63018&oldid=62997 [2] http://en.opensuse.org/index.php?title=openSUSE%3ADevelopment_Process_Details&diff=63017&oldid=62718 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mit, 2013-09-25 at 15:01 -0400, Robert Schweikert wrote:

For the second part of this paragraph I think it will be important to here from teams like the GNOME and KDE teams that determine major "features". Kernel and tool chain developers should also chime in. While I am not intimately familiar with all the things that go on in this area I have a feeling it is a lot less planned and more organic than the proposed paragraph makes it sound.

Let me try to answer that in the name of the GNOME Team: What we usually do (and also did for 13.1) is to take coolo's 'schedule', match this up with GNOME's schedule (which is luckily rather reliable and strict, incl. the beta's and RCs). Then we try to squeeze and bump as needed to make things work. But,for example for 13.1, it was known very early that we are 'aiming' at 3.10; in 12.3 we had the goal 3.6; we had to 'skip' 3.8 due to mis-aligned release dates between the two projects. For the GNOME Team this is absolutely crucial information, as we need to know EARLY if we should start checking in 3.<odd> numbers or now. We are not willing to ship any unstable in the final release... so, for one part, we do 'plan' the version... but certainly much less the features (those are planned by GNOME Upstream, where we have some 'say' as well, but as in most projects: who does, wins).

As mentioned previously this second part of the paragraph just makes it sound we work off a predetermined list for "features", i.e. versions of upstream projects. It is my perception that this is not the case. I think packages just evolve throughout the release cycle and when we reach the various feature freeze point we end up with what happens to be in factory. I don't think anyone can tell at the beginning of the cycle whether we'll end up with kernel 3.12, 3.13, or other. It all depends on upstream releases, while for some parts are reasonably regular but still subject to fluctuation, and the time available for packagers to catch up to the upstream releases. For example if we would ship 13.1 with GNOME 3.8 instead of GNOME 3.10 I don't think there would be anyone able to point to any document/e-mail/FATE reference and say "but you promised GNOME 3.10." In the end "things just happen", at least that is my perception of the "process". But others that maintain larger parts of the distribution need to chime in.

Well, we do 'try' to maintain a GOALS page for the various versions of openSUSE; for 13.1 for example: http://en.opensuse.org/openSUSE:Goals_13.1 But, you are right: there is no strict 'adherence' to this list (like, we for sure did not get rid of GStreamer 0.10) Other things catch us a bit more by surprise (like the bluetooth 5 stack requirements; and what all around this needs to be done.. we're still working on that!) Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, first of all, thanks for reading the document and provide feedback. We will digest it and propose changes. I am not qualify to answer about the concrete technical proposals. So other Team member will answer them Please read below for further comments related with the "motivations" and goals. On Friday 20 September 2013 22:31:40 Richard Brown wrote:

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.

As stated in the blog post[1] we published a few days ago, the first and biggest motivation for writing the document has been: "Starting in July 2012, the openSUSE Team at SUSE has put effort in documenting the Development + Release process. Throughout the years, the process has evolved and some of those changes were not documented or the documentation was not up to date. We have taken the opportunity to analyze the the Dev+Release process, so we could learn from it and being able to design and execute changes to improve it." ...and there is another paragraph in this direction... "This process has allowed us to analyze and discuss the process as a team, learning not just about the hows but the whys. It has also worked as a test for documenting future changes in how openSUSE is developed. We also hope that the effort can be worth it to contributors that want to get a high level view of how openSUSE works, since some of the tasks are done in house. This document has to be seen also as an exercise of transparency." Your assumptions about our main motivations for writing the document are not accurate.

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."

From your proposal I assume that removing the fourth goal might address your concerns. Is that correct? If it is, I do not see any problem on that.

Thanks again for reading the document and put effort on this.. [1] http://lizards.opensuse.org/2013/09/18/documenting-the-opensuse-development-... Saludos -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com