[opensuse-factory] Policies, or why it's good to know how to change things
Hi all, We got lots of feedback from you all, also on the process. Many did not appreciate the long and complicated emails. We discussed this in the team and Tomáš Chvátal told us how Gentoo shares a nicely documented change process with Python and Debian already. Essentially, they use a standardized document which ensures that whenever something has to be discussed, all information is there right at the start. This shortens discussions, avoids bikeshedding (see [1]) and afterwards you have a nice stash of proper proposals in archive. The proposal is essentially based off of the Python document, simplified and adapted to openSUSE. It does not change how decisions are made or by who, just speeds up the process, keeps the discussions clean and documents their results thus avoiding future flames. We think it would be great for openSUSE to adapt them. Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-) Note that the draft we made only proposes to use this for big changes to our process, not technical things like replacing sysvinit with systemd. FYI, Agustin has written on our team blog about the proposals, giving an overview of what's out: http://lizards.opensuse.org/?p=10230 -- The openSUSE Team [1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
Hey, On 11.12.2013 12:00, Antonio Larrosa wrote:
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
Can you please tell us a couple of real world factory examples where this would be useful? Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 11 December 2013 15:03:25 Henne Vogelsang wrote:
Hey,
On 11.12.2013 12:00, Antonio Larrosa wrote:
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
Can you please tell us a couple of real world factory examples where this would be useful?
Sure. Think about things like changing the legal review process or introducing staging projects. Or, as example, in our team, we're discussing if a package, after having gone through a staging project, should always first go through Devel projects or can sometimes directly go to Factory. Note that this should be for concrete implementation proposals, not for the high-level discussions like 'should we consider gamification features or not". And note that this means that when we get to concrete proposals, over the coming months, we, as openSUSE team, will then use this process to discuss the changes we'd like to work on.
Henne
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/11/2013 06:00 AM, Antonio Larrosa wrote:
Hi all,
We got lots of feedback from you all, also on the process. Many did not appreciate the long and complicated emails. We discussed this in the team and Tomáš Chvátal told us how Gentoo shares a nicely documented change process with Python and Debian already. Essentially, they use a standardized document which ensures that whenever something has to be discussed, all information is there right at the start. This shortens discussions, avoids bikeshedding (see [1]) and afterwards you have a nice stash of proper proposals in archive.
The proposal is essentially based off of the Python document, simplified and adapted to openSUSE. It does not change how decisions are made or by who, just speeds up the process, keeps the discussions clean and documents their results thus avoiding future flames. We think it would be great for openSUSE to adapt them.
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
Note that the draft we made only proposes to use this for big changes to our process, not technical things like replacing sysvinit with systemd.
FYI, Agustin has written on our team blog about the proposals, giving an overview of what's out: http://lizards.opensuse.org/?p=10230
-- The openSUSE Team
[1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
Do we really need to discuss yet another topic that is only tangentially related to the things we have already started, release cycle, openQA, and changes to Factory? I think this can wait until some of the other basic stuff is sorted out. We really do not have to discuss all the topics at the same time. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect 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
On Wed, Dec 11, 2013 at 09:09:45AM -0500, Robert Schweikert wrote:
On 12/11/2013 06:00 AM, Antonio Larrosa wrote:
Hi all,
We got lots of feedback from you all, also on the process. Many did not appreciate the long and complicated emails. We discussed this in the team and Tomáš Chvátal told us how Gentoo shares a nicely documented change process with Python and Debian already. Essentially, they use a standardized document which ensures that whenever something has to be discussed, all information is there right at the start. This shortens discussions, avoids bikeshedding (see [1]) and afterwards you have a nice stash of proper proposals in archive.
The proposal is essentially based off of the Python document, simplified and adapted to openSUSE. It does not change how decisions are made or by who, just speeds up the process, keeps the discussions clean and documents their results thus avoiding future flames. We think it would be great for openSUSE to adapt them.
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
Note that the draft we made only proposes to use this for big changes to our process, not technical things like replacing sysvinit with systemd.
FYI, Agustin has written on our team blog about the proposals, giving an overview of what's out: http://lizards.opensuse.org/?p=10230
-- The openSUSE Team
[1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
Do we really need to discuss yet another topic that is only tangentially related to the things we have already started, release cycle, openQA, and changes to Factory?
I think this can wait until some of the other basic stuff is sorted out.
Or to postpone the already running discussions and restart them in a new process? I meant, despite my willingness, I have failed to follow all the topics and discussions have happened at various places. So atm I have no clue what is happening in this project. Having something more clear from the beggining would be very valuable, so I am for a restart as there is probably nothing more than a few weeks, we will lose.
We really do not have to discuss all the topics at the same time.
<joke>You MUST propose an OSEP about accepted number of topics discussed at the same time ;-)</joke> Regards Michal Vyskocil
Robert Schweikert - 9:09 11.12.13 wrote:
Do we really need to discuss yet another topic that is only tangentially related to the things we have already started, release cycle, openQA, and changes to Factory?
This one actually makes a sense in a way, that it proposes a way so summarize all these discussions so far so people know what happened there without reading tons of mails ;-) -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Dec 11, 2013 at 12:00:25PM +0100, Antonio Larrosa wrote:
Hi all,
We got lots of feedback from you all, also on the process. Many did not appreciate the long and complicated emails. We discussed this in the team and Tomáš Chvátal told us how Gentoo shares a nicely documented change process with Python and Debian already. Essentially, they use a standardized document which ensures that whenever something has to be discussed, all information is there right at the start. This shortens discussions, avoids bikeshedding (see [1]) and afterwards you have a nice stash of proper proposals in archive.
The proposal is essentially based off of the Python document, simplified and adapted to openSUSE. It does not change how decisions are made or by who, just speeds up the process, keeps the discussions clean and documents their results thus avoiding future flames. We think it would be great for openSUSE to adapt them.
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
Note that the draft we made only proposes to use this for big changes to our process, not technical things like replacing sysvinit with systemd.
FYI, Agustin has written on our team blog about the proposals, giving an overview of what's out: http://lizards.opensuse.org/?p=10230
-- The openSUSE Team
[1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
Hi openSUSE team, I appreciate such move from unstructured mess of various email threads and discussions to something much easier to deal with and to follow!
_____________________________________________________________________ OSEP: 0001 Title: Process proposal: openSUSE Enhancement Proposal Version: 0.1 Last-Modified: 10 Dec 2013 Author: Jos Poortvliet <jpoortvliet@suse.de>, Antonio Larrosa <alarrosa@suse.de> Status: Draft Type: Process Created: 02 Dec 2013 Post-History: _____________________________________________________________________
Process proposal: openSUSE Enhancement Proposal -----------------------------------------------
OSEP (_openSUSE Enhancement Proposal_) is a document providing information to the openSUSE community or describing a process in Factory or its environment. The OSEP should provide a concise specification and rationale of the process it's explaining.
OSEPs are intended to be the primary mechanisms for proposing major new procedures and for documenting the design decisions that have gone into Factory. The OSEP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the OSEPs are maintained as text files in a versioned repository, their revision history is the historical record of each proposal footnoteref:[note_repo, https://www.github.com/TBD].
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
OSEP Types ----------
There are two kinds of OSEP:
- An _Informational OSEP_ describes an issue, or provides general guidelines or information to the openSUSE developers, but does not propose a new feature. Informational OSEPs do not necessarily represent a community consensus or recommendation, so users and implementers are free to ignore Informational OSEPs or follow their advice.
What is the reason to spent a time on creating and discussing a proposal, which will ends in informational state? Do you have any example, where the process is worth effort, but the result is not that important?
- A _Process OSEP_ describes a process surrounding Factory, or proposes a change to a process. They may propose an implementation, but not to packages; they often require community consensus; unlike Informational OSEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, changes to the decision-making process, and changes to the tools or environment used in Factory development.
Submitting an OSEP ------------------
The OSEP process begins with a new idea for openSUSE. It is highly recommended that a single OSEP contain a single key proposal or new idea. Small enhancements or patches don't need an OSEP.
It's recommended that the author of an OSEP brings his/her idea to key people from the community to see the acceptance the idea would have before sending it for review. The received feedback should be introduced in the first draft document, so that it's as complete as possible and long open-ended discussions on public mailing lists are avoided.
Once a draft is written in the style described below, it should be presented to the _opensuse-factory_ mailing list.
it MUST be presented on opensuse-$FOO mailinglist - having mandatory OSEP not beeing discussed in a public is a no-go. Please make sure you use the keywords as defined in RFC2119 http://www.ietf.org/rfc/rfc2119.txt
OSEPs should be submitted in asciidoc format footnoteref:[asciidoc_userguide, http://www.methods.co.nz/asciidoc/userguide.html] with UTF-8 codification.
OSEPs may include auxiliary files such as diagrams. Such files must be named +osep-XXXX-Y.ext+, where _XXXX_ is the OSEP number, _Y_ is a serial number (starting at 1), and _ext_ is replaced by the actual file extension (e.g. +png+).
Again, what is wrong with a wiki? Pages can be even blocked, so only author can change them ... there can be even a template and fancy boxes for a state. And it is not that hard to get the text form to send it to ML. Regards Michal Vyskocil
[snip]
Michal Vyskocil - 15:10 11.12.13 wrote:
...
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
hmmm, interesting idea, never thought about wiki as I know Gentoo does it this way. Maybe somebody else would have some idea about the reasoning behind. Thinking about using wiki, my first few thoughts: - we would need to create a new namespace and limit access and check how access rights in wiki works - means some work, but once set up, could work - harder/trickier submission of new OSEPs and changes * preparing somewhere, asking for a page/access, copy the result over vs pull request (which we can even link in mailing list discussion) + people are more familiar with wiki than with asciidoc * asciidoc could support multiple formats for easier printing/offline/mobile browsing, although I don't think this is important, just a cherry on top But I would say that this is definitely a good idea to discuss :-) -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 11 December 2013 15:56:31 Michal Hrusecky wrote:
Michal Vyskocil - 15:10 11.12.13 wrote:
...
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
hmmm, interesting idea, never thought about wiki as I know Gentoo does it this way. Maybe somebody else would have some idea about the reasoning behind. Thinking about using wiki, my first few thoughts:
- we would need to create a new namespace and limit access and check how access rights in wiki works - means some work, but once set up, could work - harder/trickier submission of new OSEPs and changes * preparing somewhere, asking for a page/access, copy the result over vs pull request (which we can even link in mailing list discussion) + people are more familiar with wiki than with asciidoc * asciidoc could support multiple formats for easier printing/offline/mobile browsing, although I don't think this is important, just a cherry on top
But I would say that this is definitely a good idea to discuss :-) Yeah, we (in Nue) noticed we hadn't thought about this either, but just adopted what was in the Gentoo doc. Yet, as Ludwig pointed out here, most of our policies are in the wiki, so that's the natural place for these OSEPs :D
Good suggestion, thus. /J -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Hrusecky - 15:56 11.12.13 wrote:
Michal Vyskocil - 15:10 11.12.13 wrote:
...
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
hmmm, interesting idea, never thought about wiki as I know Gentoo does it this way. Maybe somebody else would have some idea about the reasoning behind. Thinking about using wiki, my first few thoughts:
- we would need to create a new namespace and limit access and check how access rights in wiki works - means some work, but once set up, could work - harder/trickier submission of new OSEPs and changes * preparing somewhere, asking for a page/access, copy the result over vs pull request (which we can even link in mailing list discussion) + people are more familiar with wiki than with asciidoc * asciidoc could support multiple formats for easier printing/offline/mobile browsing, although I don't think this is important, just a cherry on top
But I would say that this is definitely a good idea to discuss :-)
So, let's make cons & pros list, or wiki vs github list. Wiki is good for collaborative documentation, but for something like RFC, we probably want something less changeable, but that could be arranged in the wiki as well probably... Wiki: Pros: * people know how to write there * we have it already Cons: * we would have to setup some rights system and test it * hard merging and discussion of changes * not easy to prepare full OSEP, review it and merge it Github: Pros: * easy way to merge and review changes * easy way to submit new OSEP * rights management for free * we can accept only full proposals Cons: * not everybody knows asciidoc * yet another place for documentation although little promotion could cover that What did I missed? -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Dec 12, 2013 at 11:30:02AM +0100, Michal Hrusecky wrote:
Michal Hrusecky - 15:56 11.12.13 wrote:
Michal Vyskocil - 15:10 11.12.13 wrote:
...
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
hmmm, interesting idea, never thought about wiki as I know Gentoo does it this way. Maybe somebody else would have some idea about the reasoning behind. Thinking about using wiki, my first few thoughts:
- we would need to create a new namespace and limit access and check how access rights in wiki works - means some work, but once set up, could work - harder/trickier submission of new OSEPs and changes * preparing somewhere, asking for a page/access, copy the result over vs pull request (which we can even link in mailing list discussion) + people are more familiar with wiki than with asciidoc * asciidoc could support multiple formats for easier printing/offline/mobile browsing, although I don't think this is important, just a cherry on top
But I would say that this is definitely a good idea to discuss :-)
So, let's make cons & pros list, or wiki vs github list. Wiki is good for collaborative documentation, but for something like RFC, we probably want something less changeable, but that could be arranged in the wiki as well probably...
Wiki: Pros: * people know how to write there * we have it already Cons: * we would have to setup some rights system and test it * hard merging and discussion of changes * not easy to prepare full OSEP, review it and merge it
Github: Pros: * easy way to merge and review changes * easy way to submit new OSEP * rights management for free * we can accept only full proposals Cons: * not everybody knows asciidoc * yet another place for documentation although little promotion could cover that
What did I missed?
Wiki: Pros: * people know how to write there * we have it already + * easy way to review changes ever heard about page history? + * easy way to submit new OSEP wiki is designed for making submissions easy to anyone
Cons: * we would have to setup some rights system and test it why? anyway wikimedia does support that since beggining [1] * hard merging and discussion of changes have you ever hear about Talk pages? but discussions should happen on ML by default * not easy to prepare full OSEP, review it and merge it cm'n, wiki is designed for this use case - or do you really expect dozens of pull requests for documentation?
The easiest approach is 1.) $OWNER write OSEP proposal and put it into wiki with proper Category 2.) Then sent it as an attachement to ML 3.) Changes are merged by $OWNER back to wiki 4.) Once agreed, OSEP is accepted 5.) profit! I really do not see any particular advantage of git in this specific case. And btw all OSEPs can be watched, so people can be warned on edit. Please KISS! [1] http://en.wikipedia.org/wiki/Wikipedia:Blocking_policy Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Vyskocil - 15:09 12.12.13 wrote:
Wiki: Pros: * people know how to write there * we have it already + * easy way to review changes ever heard about page history?
Sent patch that goes through review?
+ * easy way to submit new OSEP wiki is designed for making submissions easy to anyone
Sent new page to namespace/category and wait for review?
Cons: * we would have to setup some rights system and test it why? anyway wikimedia does support that since beggining [1]
Ok, never tried that :-)
* hard merging and discussion of changes
have you ever hear about Talk pages? but discussions should happen on ML by default
Talk is not answer, mailing list is, I still think about something like patch review...
* not easy to prepare full OSEP, review it and merge it
cm'n, wiki is designed for this use case - or do you really expect dozens of pull requests for documentation?
In my experience wiki is designed and used as everybodys playground with hopes that in the end some structure and something usable will emerge and that google will be able to index it good enough :-D
The easiest approach is 1.) $OWNER write OSEP proposal and put it into wiki with proper Category 2.) Then sent it as an attachement to ML 3.) Changes are merged by $OWNER back to wiki 4.) Once agreed, OSEP is accepted 5.) profit!
I really do not see any particular advantage of git in this specific case. And btw all OSEPs can be watched, so people can be warned on edit. Please KISS!
In general what I'm afraid of is openFATE, which is generally everyones wish list. So I would prefer to have at least some entry barrier. But maybe moving pages and access rights in wiki are the answer. In general, I admit that I'm biased and that I like git much more than wiki, but looks like wiki could be maybe made to work. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hey, On 11.12.2013 15:56, Michal Hrusecky wrote:
Michal Vyskocil - 15:10 11.12.13 wrote:
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
hmmm, interesting idea, never thought about wiki as I know Gentoo does it this way. Maybe somebody else would have some idea about the reasoning behind. Thinking about using wiki, my first few thoughts:
- we would need to create a new namespace and limit access and check how access rights in wiki works - means some work, but once set up, could work
I don't see why you would need a new namespace. You can simply have a decent site template with categorization in openSUSE: and a Portal to tie it all together.
- harder/trickier submission of new OSEPs and changes * preparing somewhere, asking for a page/access, copy the result over vs pull request (which we can even link in mailing list discussion)
Hm why would you need access rights at all? I could just start openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the "key people" and if they like it, propose it to the mailing list. Once it's discussed, you can reference the discussion and change the category to Accpeted_OSEPs etc. etc. No need for access rights.... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Henne Vogelsang - 13:25 12.12.13 wrote:
Hey,
On 11.12.2013 15:56, Michal Hrusecky wrote:
Michal Vyskocil - 15:10 11.12.13 wrote:
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
hmmm, interesting idea, never thought about wiki as I know Gentoo does it this way. Maybe somebody else would have some idea about the reasoning behind. Thinking about using wiki, my first few thoughts:
- we would need to create a new namespace and limit access and check how access rights in wiki works - means some work, but once set up, could work
I don't see why you would need a new namespace. You can simply have a decent site template with categorization in openSUSE: and a Portal to tie it all together.
hmm, to make it findable and reachable and not that messy?
- harder/trickier submission of new OSEPs and changes * preparing somewhere, asking for a page/access, copy the result over vs pull request (which we can even link in mailing list discussion)
Hm why would you need access rights at all? I could just start openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the "key people" and if they like it, propose it to the mailing list. Once it's discussed, you can reference the discussion and change the category to Accpeted_OSEPs etc. etc. No need for access rights....
To ensure nobody randomly messes up with it without prior agreement on mailing list and to make sure all changes are agreed upon and discussion leading to it is documented. What would prevent me from putting document saying that everybody needs to wear pink hat's into that category? It wouldn't pass the review probably, but apart from that? -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/2013 07:55 AM, Michal Hrusecky wrote:
Henne Vogelsang - 13:25 12.12.13 wrote:
Hey,
On 11.12.2013 15:56, Michal Hrusecky wrote:
Michal Vyskocil - 15:10 11.12.13 wrote:
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
hmmm, interesting idea, never thought about wiki as I know Gentoo does it this way. Maybe somebody else would have some idea about the reasoning behind. Thinking about using wiki, my first few thoughts:
- we would need to create a new namespace and limit access and check how access rights in wiki works - means some work, but once set up, could work
I don't see why you would need a new namespace. You can simply have a decent site template with categorization in openSUSE: and a Portal to tie it all together.
hmm, to make it findable and reachable and not that messy?
- harder/trickier submission of new OSEPs and changes * preparing somewhere, asking for a page/access, copy the result over vs pull request (which we can even link in mailing list discussion)
Hm why would you need access rights at all? I could just start openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the "key people" and if they like it, propose it to the mailing list. Once it's discussed, you can reference the discussion and change the category to Accpeted_OSEPs etc. etc. No need for access rights....
To ensure nobody randomly messes up with it without prior agreement on mailing list and to make sure all changes are agreed upon and discussion leading to it is documented. What would prevent me from putting document saying that everybody needs to wear pink hat's into that category? It wouldn't pass the review probably, but apart from that?
Makes me wonder why we do not have a million wiki pages that require everyone to wear pink hats. Do we really have such a big trust problem as you are displaying here? If that is the case we have other issues to discuss that would, IMHO, take precedence over everything else. The wiki is open, enables easy collaboration and has a history, thus it is still easy to see who made the changes. And the person that added the pink hats requirement can be asked why that would be a potentially good idea. Later, Robert
-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect 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
Robert Schweikert - 8:14 12.12.13 wrote:
...
The wiki is open, enables easy collaboration and has a history, thus it is still easy to see who made the changes. And the person that added the pink hats requirement can be asked why that would be a potentially good idea.
The point of OSEP is to document the agreement, not to collaborate on document easily. And be the source of trusted information. All changes should be discussed. Not that somebody switches blue hats for pink hats and after new ambassador creates tons of pink hats he will find out, that somebody just though that blue meant pink and pink was nicer formulation. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/2013 08:24 AM, Michal Hrusecky wrote:
Robert Schweikert - 8:14 12.12.13 wrote:
...
The wiki is open, enables easy collaboration and has a history, thus it is still easy to see who made the changes. And the person that added the pink hats requirement can be asked why that would be a potentially good idea.
The point of OSEP is to document the agreement, not to collaborate on document easily.
Yeah, <sarcasm> it would be horrible if multiple people work on the same proposal in the open.</sarcasm>
And be the source of trusted information.
So you are implying that non of the information on our wiki can be trusted?
All changes should be discussed. Not that somebody switches blue hats for pink hats and after new ambassador creates tons of pink hats he will find out, that somebody just though that blue meant pink and pink was nicer formulation.
I do not like where this is going at all. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect 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
Robert Schweikert - 8:31 12.12.13 wrote:
On 12/12/2013 08:24 AM, Michal Hrusecky wrote:
Robert Schweikert - 8:14 12.12.13 wrote:
...
The wiki is open, enables easy collaboration and has a history, thus it is still easy to see who made the changes. And the person that added the pink hats requirement can be asked why that would be a potentially good idea.
The point of OSEP is to document the agreement, not to collaborate on document easily.
Yeah, <sarcasm> it would be horrible if multiple people work on the same proposal in the open.</sarcasm>
Proposal yes, not everybody randomly putting his idea into same wiki page creating flame with hundreds of revisions in the wiki instead of mailing list.
And be the source of trusted information.
So you are implying that non of the information on our wiki can be trusted?
No. Authoritative was the word I was searching for. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Hrusecky - 14:24 12.12.13 wrote:
Robert Schweikert - 8:14 12.12.13 wrote:
...
The wiki is open, enables easy collaboration and has a history, thus it is still easy to see who made the changes. And the person that added the pink hats requirement can be asked why that would be a potentially good idea.
The point of OSEP is to document the agreement, not to collaborate on document easily. And be the source of trusted information. All changes should be discussed. Not that somebody switches blue hats for pink hats and after new ambassador creates tons of pink hats he will find out, that somebody just though that blue meant pink and pink was nicer formulation.
Think about it in terms like RFC, JEP, ISO, ... It's something you create, agree upon and then never ever modify once accepted, unless patch goes through the mailing list review process. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Michal Hrusecky <mhrusecky@suse.cz>:
Michal Hrusecky - 14:24 12.12.13 wrote:
Robert Schweikert - 8:14 12.12.13 wrote:
...
The wiki is open, enables easy collaboration and has a history, thus it is still easy to see who made the changes. And the person that added the pink hats requirement can be asked why that would be a potentially good idea.
The point of OSEP is to document the agreement, not to collaborate on document easily. And be the source of trusted information. All changes should be discussed. Not that somebody switches blue hats for pink hats and after new ambassador creates tons of pink hats he will find out, that somebody just though that blue meant pink and pink was nicer formulation.
Think about it in terms like RFC, JEP, ISO, ... It's something you create, agree upon and then never ever modify once accepted, unless patch goes through the mailing list review process.
Over-complicating the process doesn't help in the end. A Wiki page can be locked (see the SDB: namespace for example. Only a handful of users can actually make changes visible). That sounds sufficient to 'ensure an agreed standard is not changed'. Until it is locked, it can't be considered 'agreed' or ready for approval, but in fact _open_ for collaboration. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/2013 03:00 PM, Dominique Leuenberger a.k.a. Dimstar wrote:
That sounds sufficient to 'ensure an agreed standard is not changed'. Until it is locked, it can't be considered 'agreed' or ready for approval, but in fact _open_ for collaboration.
But that means some discussion would happen on the wiki page and some discussions would happen in the mailing list. Isn't it better to have a single place for discussion and then a document that reflects the conclusions? -- Antonio Larrosa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/2013 09:56 AM, Antonio Larrosa wrote:
On 12/12/2013 03:00 PM, Dominique Leuenberger a.k.a. Dimstar wrote:
That sounds sufficient to 'ensure an agreed standard is not changed'. Until it is locked, it can't be considered 'agreed' or ready for approval, but in fact _open_ for collaboration.
But that means some discussion would happen on the wiki page and some discussions would happen in the mailing list. Isn't it better to have a single place for discussion and then a document that reflects the conclusions?
I think there is no way to prevent the "two places" problem other than convention. Even if we were to use github. People can leave comments there just as well as in the wiki discussion. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect 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
On Thu, 12 Dec 2013 10:03:51 -0500, Robert Schweikert wrote:
I think there is no way to prevent the "two places" problem other than convention. Even if we were to use github. People can leave comments there just as well as in the wiki discussion.
Well, the obvious solution (at least to me) is to make it really abundantly clear that if you want your input considered, you need to make it in the "official" place. We do this all the time on the forums - people report bugs, and while we'll help determine if it is a bug, in the end if they don't submit a bug to bugzilla, it's not going to get addressed. This is particularly true of the "troll-like" posts we get in the few weeks following a new release from people saying "it was released too soon" or "nothing works" (or similar). If they didn't participate in the beta (which arguably not everyone can do) and don't ask for help and submit bugs when they run into a problem, how do they expect anyone to know there's a bug to be fixed? You can't assume that testing is going to catch 100% of the defects, and you can't wait until 100% of defects are fixed before shipping. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/13 13:55, Michal Hrusecky wrote:
To ensure nobody randomly messes up with it without prior agreement on mailing list and to make sure all changes are agreed upon and discussion leading to it is documented. What would prevent me from putting document saying that everybody needs to wear pink hat's into that category? It wouldn't pass the review probably, but apart from that?
You should trust your fellow co-developers more, and cope with the fallout for the rare cases of a bad apple. openSUSE is not a stub-in-the-back corporate environment, IMNSHO. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Joachim Schrod - 1:16 13.12.13 wrote:
On 12/12/13 13:55, Michal Hrusecky wrote:
To ensure nobody randomly messes up with it without prior agreement on mailing list and to make sure all changes are agreed upon and discussion leading to it is documented. What would prevent me from putting document saying that everybody needs to wear pink hat's into that category? It wouldn't pass the review probably, but apart from that?
You should trust your fellow co-developers more, and cope with the fallout for the rare cases of a bad apple. openSUSE is not a stub-in-the-back corporate environment, IMNSHO.
Wiki is editable by everybody, not only co-developers, but basically anybody who goes around and bothers to create account. Confused newbies that haven't read the first OSEP but would think of cool additional documentation that is currently not required part of the process but some teams use it? -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/13/13 06:39, Michal Hrusecky wrote:
Joachim Schrod - 1:16 13.12.13 wrote:
On 12/12/13 13:55, Michal Hrusecky wrote:
To ensure nobody randomly messes up with it without prior agreement on mailing list and to make sure all changes are agreed upon and discussion leading to it is documented. What would prevent me from putting document saying that everybody needs to wear pink hat's into that category? It wouldn't pass the review probably, but apart from that?
You should trust your fellow co-developers more, and cope with the fallout for the rare cases of a bad apple. openSUSE is not a stub-in-the-back corporate environment, IMNSHO.
Wiki is editable by everybody, not only co-developers, but basically anybody who goes around and bothers to create account. Confused newbies that haven't read the first OSEP but would think of cool additional documentation that is currently not required part of the process but some teams use it?
IMHO, looking at the openSUSE wiki, our current issue is that too few people edit there, not too many. I prophesize that the same will happen with OSEP pages. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: jschrod@acm.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 12 Dec 2013 13:55:11 +0100 Michal Hrusecky <mhrusecky@suse.cz> wrote:
To ensure nobody randomly messes up with it without prior agreement on mailing list and to make sure all changes are agreed upon and discussion leading to it is documented.
There is few ways to protect content in a wiki. Besides "Protect" that is visible to users that belong to administrator accounts, which has few levels of protection, there is extension "Flagged Reviews" which presents to readers approved version of text. This gives administrators opportunity to act on vandalism before anyone can see it. In other words people following your link will not see pink slippers instead of blue, although someone actually changed that. Apropos, namespace "OSEP:", that could be required, so that we can enable Flagged Revisions for that name space. The "openSUSE;" is not included in this extension as it was considered work space where protection would make more trouble then help. We have another extension that prevents edit of user pages (User:XYZ pages), but I never tested it. It should allow only user and wiki admins to change page, which would be ideal in case of OSEP proposal. When accepted it can be moved to openSUSE namespace and protected. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/2013 01:25 PM, Henne Vogelsang wrote:
Hm why would you need access rights at all? I could just start openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the "key people" and if they like it, propose it to the mailing list. Once it's discussed, you can reference the discussion and change the category to Accpeted_OSEPs etc. etc. No need for access rights....
Well, you for sure don't want someone to be able to modify an accepted OSEP with something different than what was accepted, right? Even if it's possible to look in the page history and revert the change, it's better if those problems can be prevented before happening (less work => more happiness :) ) -- Antonio Larrosa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/2013 08:04 AM, Antonio Larrosa wrote:
On 12/12/2013 01:25 PM, Henne Vogelsang wrote:
Hm why would you need access rights at all? I could just start openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the "key people" and if they like it, propose it to the mailing list. Once it's discussed, you can reference the discussion and change the category to Accpeted_OSEPs etc. etc. No need for access rights....
Well, you for sure don't want someone to be able to modify an accepted OSEP with something different than what was accepted, right? Even if it's possible to look in the page history and revert the change, it's better if those problems can be prevented before happening (less work => more happiness :) )
more mistrust -> more FUD -> the dark side Come on people, really that's your argument. We are, at least I hope not, not in a community where people are after each other. If that's what we are becoming with all of this then we will not be a viable community for long. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect 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, On Thursday, December 12, 2013 08:17:20 AM Robert Schweikert wrote:
On 12/12/2013 08:04 AM, Antonio Larrosa wrote:
On 12/12/2013 01:25 PM, Henne Vogelsang wrote:
Hm why would you need access rights at all? I could just start openSUSE:My_proposal-0001 in the category Draft_OSEPs, show it to the "key people" and if they like it, propose it to the mailing list. Once it's discussed, you can reference the discussion and change the category to Accpeted_OSEPs etc. etc. No need for access rights....
Well, you for sure don't want someone to be able to modify an accepted OSEP with something different than what was accepted, right? Even if it's possible to look in the page history and revert the change, it's better if those problems can be prevented before happening (less work => more happiness :) )
more mistrust -> more FUD -> the dark side
Come on people, really that's your argument. We are, at least I hope not, not in a community where people are after each other. If that's what we are becoming with all of this then we will not be a viable community for long.
I do not consider Python or Gentoo not viable communities. There are many things we can learn and adapt from them. This is about if it is more convenient to use the wiki or github as tool for OSEP. I consider this a detail that can be decided by those who will take care of the process. I find good points in both options. The proposal is about having a well established and simple procedure to propose, discuss, decide and document relevant changes in the development process, improving our current situation. I think it is a good goal. Saludos -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 12 Dec 2013 14:04:58 +0100 Antonio Larrosa <alarrosa@suse.de> wrote:
Even if it's possible to look in the page history and revert the change, it's better if those problems can be prevented before happening (less work => more happiness :) )
Let me repeat: ... there is extension "Flagged Reviews" which presents to readers approved version of text. This gives administrators opportunity to act on vandalism before anyone can see it. More: https://www.mediawiki.org/wiki/Extension:FlaggedRevs Another internal wiki tool can hide from history listing, or logs, all traces that vandalism happened, which prevents smart vandals that use comments in article history to make their opinion permanent. The only trace that something happened is empty entry in a history. From admin account that looks like: (show/hide) 09:06, 2 August 2012 Rajko m (Talk | contribs | block) moved page Template:AMD Navbar to Template:AMD navbar (Capitalization - "AMD Navbar" will not show up if wiki editor uses common "AMD navbar" ) (revert) If needed admin can hide log entry, or parts of it. I have feeling that mistrust in the wiki comes from not knowing its properties. To publish text, wiki is first choice, and also important is that wiki is our local resource. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 14 Dec 2013 01:11:47 -0600 Rajko <rmatov101@charter.net> wrote:
On Thu, 12 Dec 2013 14:04:58 +0100 Antonio Larrosa <alarrosa@suse.de> wrote:
Even if it's possible to look in the page history and revert the change, it's better if those problems can be prevented before happening (less work => more happiness :) )
To make discussion where to keep OSEP shorter here is example of wiki variant: https://en.opensuse.org/openSUSE:OSEP_0001 which is listed at: https://en.opensuse.org/Portal:OSEP and https://en.opensuse.org/Category:OSEP I followed what Henne said, which is not optimal as "openSUSE:" namespace is not protected with Flagged Reviews, in other words document must be protected in a classic way, which is already done. Changes are not possible for new and not registered users. Next level would be to make only admins able to change text, which can be applied when final version is available. Portal can be arranged in different ways. Current is only to illustrate different options to list OSEP. OSEP 0001 is listed in fixed text mode, the same used in ML, which is not optimal. RFC, which is model for OSEP, was created at different time with a lot lesser common infrastructure that can be accessed by everyone, so it is used fixed text with some fields dedicated to manual version control. I don't think we need that this days. Web browser is ubiquitous, wiki has a version control, and OSEP should reflect that. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/11/2013 03:10 PM, Michal Vyskocil wrote:
I appreciate such move from unstructured mess of various email threads and discussions to something much easier to deal with and to follow!
Thanks.
Because the OSEPs are maintained as text files in a versioned repository, their revision history is the historical record of each proposal footnoteref:[note_repo, https://www.github.com/TBD].
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
Yes, I think you're right. As long as proper access permissions work in the wiki and if nobody says anything against this idea in the following days, I'm changing that into the OSEP (I'll have a look first just to check how permissions work there and if they're good enough for our needs).
OSEP Types ----------
There are two kinds of OSEP:
- An _Informational OSEP_ describes an issue, or provides general guidelines or information to the openSUSE developers, but does not propose a new feature. Informational OSEPs do not necessarily represent a community consensus or recommendation, so users and implementers are free to ignore Informational OSEPs or follow their advice.
What is the reason to spent a time on creating and discussing a proposal, which will ends in informational state? Do you have any example, where the process is worth effort, but the result is not that important?
Think something like: http://www.gentoo.org/proj/en/glep/glep-0057.html It's mainly a series of definitions so that other GLEPs can use those concepts.
Once a draft is written in the style described below, it should be presented to the _opensuse-factory_ mailing list.
it MUST be presented on opensuse-$FOO mailinglist - having mandatory OSEP not beeing discussed in a public is a no-go.
Completely correct. I think I originally wrote there "it should be presented to the opensuse-factory or opensuse-project mailing lists", then changed it to just opensuse-factory to have just one entry point for OSEPs, but in any case, you're right it MUST say MUST. I won't send again the fixed OSEP-0001 in order not to spam the list (at least, not for a few days so that we can collect more fixes), but consider your changes included. Greetings, -- Antonio Larrosa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 11 Dec 2013 15:10:34 +0100 Michal Vyskocil <mvyskocil@suse.cz> wrote:
Again, what is wrong with a wiki? Pages can be even blocked, so only author can change them ... there can be even a template and fancy boxes for a state. And it is not that hard to get the text form to send it to ML.
If it is used <pre> OSEP Text </pre> then even text format will be preserved with copy-paste to email. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/11/2013 11:17 PM, Rajko wrote:
Again, what is wrong with a wiki? Pages can be even blocked, so only author can change them ... there can be even a template and fancy boxes for a state. And it is not that hard to get the text form to send it to ML. If it is used <pre> OSEP Text </pre> then even text format will be preserved with copy-paste to email.
wikis are only as good as the commitment to use them. I have seen them fail just as often as I have seen them work. They are a great tool for this job, if we groups and structure the information in a way that fits into the development process. A good example of one of the best Linux distro wikis is wiki.archlinux.org. (mediawiki) Of all the distros I've tried, their wiki is by far the best. For an example and ideas of how this could be implemented and benefit the factory effort, I encourage all to take a look. Between the package query (with full historic development changes for each package) to implementation and use informational pages for each, they have a slick way of capturing and managing critical development information. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/12/2013 08:37 PM, David C. Rankin wrote:
On 12/11/2013 11:17 PM, Rajko wrote:
Again, what is wrong with a wiki? Pages can be even blocked, so only author can change them ... there can be even a template and fancy boxes for a state. And it is not that hard to get the text form to send it to ML. If it is used <pre> OSEP Text </pre> then even text format will be preserved with copy-paste to email.
wikis are only as good as the commitment to use them. I have seen them fail just as often as I have seen them work. They are a great tool for this job, if we groups and structure the information in a way that fits into the development process. A good example of one of the best Linux distro wikis is wiki.archlinux.org. (mediawiki) Of all the distros I've tried, their wiki is by far the best. For an example and ideas of how this could be implemented and benefit the factory effort, I encourage all to take a look. Between the package query (with full historic development changes for each package) to implementation and use informational pages for each, they have a slick way of capturing and managing critical development information.
I would like to add that wiki.archlinux.org has a format that openSUSE can emulate. It is much easier to read compared to the openSUSE wiki. I like the fact that they assign different colors assigned to (Tips questions, answers, code blocks etc..) and the fonts appear easier on the eye. Hence the user has a better reading experience. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In article <52A845C9.8050108@suse.de>, Antonio Larrosa <alarrosa@suse.de> writes:
Antonio> Hi all, Antonio> We got lots of feedback from you all, also on the process. Many did not Antonio> appreciate the long and complicated emails. We discussed this in the Antonio> team and Tomáš Chvátal told us how Gentoo shares a nicely documented Antonio> change process with Python and Debian already. Essentially, they use a Antonio> standardized document which ensures that whenever something has to be Antonio> discussed, all information is there right at the start. This shortens Antonio> discussions, avoids bikeshedding (see [1]) and afterwards you have a Antonio> nice stash of proper proposals in archive. Antonio> The proposal is essentially based off of the Python Antonio> document, simplified and adapted to openSUSE. It does not Antonio> change how decisions are made or by who, just speeds up the Antonio> process, keeps the discussions clean and documents their Antonio> results thus avoiding future flames. We think it would be Antonio> great for openSUSE to adapt them. Antonio> Attached to this mail there's a draft with a recursive OSEP Antonio> in the proper, proposed form, let us know what you think Antonio> ;-) Does Gentoo or from whomever else you are taking the ideas have a timing policy of sending proposals, or RFC or what ever name you want to give. Do they also bombard with idea after idea without letting anything to settle down. I started to have the feeling that the openSUSE team has a deadline or an obligation to SUSE to achieve something or at least to show there is tangible events within this calendar year (2013). Togan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi,
Does Gentoo or from whomever else you are taking the ideas have a timing policy of sending proposals, or RFC or what ever name you want to give. Do they also bombard with idea after idea without letting anything to settle down.
I started to have the feeling that the openSUSE team has a deadline or an obligation to SUSE to achieve something or at least to show there is tangible events within this calendar year (2013).
We always have time pressures. Many think that a Release cycle is nothing but that :-) Sending the "contents" of the proposal before Christmas is something I am specially interested on. Christmas is a good time for "processing". In general, you can see the plan here: http://lizards.opensuse.org/author/calumma/ In this discussion process we have received several additional requests of information. There is one that we are preparing today which is to provide some explanations about the target and goals of the development version proposal, Factory. We are also finishing the mail about time and effort. Saludos -- Agustin Benito Bethencourt openSUSE Team Lead at SUSE abebe@suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12/11/2013 05:00 AM, Antonio Larrosa wrote:
We got lots of feedback from you all, also on the process. Many did not appreciate the long and complicated emails. We discussed this in the team and Tomáš Chvátal told us how Gentoo shares a nicely documented change process with Python and Debian already. Essentially, they use a standardized document which ensures that whenever something has to be discussed, all information is there right at the start. This shortens discussions, avoids bikeshedding (see [1]) and afterwards you have a nice stash of proper proposals in archive.
<snip>
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
What are the "Enhancement Proposals" currently called? ..and.. Is this a proposal meant to supplement or replace the current process? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
David C. Rankin - 19:28 12.12.13 wrote:
On 12/11/2013 05:00 AM, Antonio Larrosa wrote:
We got lots of feedback from you all, also on the process. Many did not appreciate the long and complicated emails. We discussed this in the team and Tomáš Chvátal told us how Gentoo shares a nicely documented change process with Python and Debian already. Essentially, they use a standardized document which ensures that whenever something has to be discussed, all information is there right at the start. This shortens discussions, avoids bikeshedding (see [1]) and afterwards you have a nice stash of proper proposals in archive.
<snip>
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
What are the "Enhancement Proposals" currently called? ..and.. Is this a proposal meant to supplement or replace the current process?
Currently, they are not called anything, they are just mails to the mailing list and the idea is to improve the process we currently have. -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (14)
-
Agustin Benito Bethencourt -
Antonio Larrosa -
David C. Rankin -
Dominique Leuenberger a.k.a. Dimstar -
Henne Vogelsang -
Jim Henderson -
Joachim Schrod -
Jos Poortvliet -
Michal Hrusecky -
Michal Vyskocil -
Rajko -
Robert Schweikert -
Roman Bysh -
Togan Muftuoglu