This is an update to the problem process workflow and to terminology. #4
Conversation
|
Some typos should be cleaned up: Slide 1: concensus, forumlation From my point of view the "Problem Proposals" are not added by the LSB work group. Everyone can file an issue, those are the proposals. By creating a "Problem Statement" and merging it the proposal is accepted as yes, we should work on this. The "Problem Statement" is not exclusively drafted by the LSB work group either, that's all work we do not really want to do. Ideally, people send a pull request with a well formulated "Problem Statement", this is then discussed and merged when we are happy with it. The Solution can also be proposed by anyone. Distribution providers agree by consensus but that does not necessarily mean the specify the solution. The "Roadmap" idea puts us, IMHO, in exactly the bind Jeff didn't want us to get into. We do not want to be responsible for tracking what distributions do. There are no enough eyes in the work group to do that. Once there is consensus and distros pledge implement we should be done. Slide 2 looks like a to do/things to consider list, from our point of view, thus it should not be intermingled with "this is how it should work" Slide 3 is a rehash of parts from #3 but uses different terminology, Problem Proposal vs Problem Statement. This is confusing. Slide 4: Again, the "Problem Proposal List" is simply the issue tracker in Github, it should be named as such, otherwise no on will know what it is. Also the Problem Statement can be formulated by anyone. If we are on the hook to do it, it'll never get done, lets be inclusive, not exclusive. We are not the elite of problem description writing ;) The rest looks more like a rehash of #3 again. If #3 is not specific enough lets work on it rather than presenting the same info in 2 different documents. Slide 5: a number of my previous comments apply. Also please remove you name, you get credit for your work in the log, what we publish should be from the work group, IMHO |
|
-1 on merging this as is. Besides Rober't comments, there's nothing here that couldn't be written out in a text file (use a .md file if it needs simple markup, or markdown as github insists on calling it). |
|
Alright, previous comment was harsh due to some strange problem on this system, there was only one slide. On bringing it up again, there are five, which includes two diagrams, makes more sense now. I'd still be happier with something that could be seen directly by browsing the repo than having to open in an external program, but I'll moderate my comment on the file type to a preference. |
|
Thanks, Robert. For starters, I will split the flowchart out from the other text and post it separately as the base started out. "From my point of view the "Problem Proposals" are not added by the LSB work group.... There is nothing in the first few boxes in the first workflow slide that says who does these things. My intent was that any one could. I added "Anyone can" to the first box to make it clearer. The first place the workgroup must specifically get involved is where it is named in the decision box. "The Solution can also be proposed by anyone." Fixed. "The "Roadmap" idea puts us, IMHO, in exactly the bind Jeff didn't want us to get into. We do not want to be responsible for tracking what distributions do. There are no enough eyes in the work group to do that. Once there is consensus and distros pledge implement we should be done." I had in my notes from the meeting last week that we would do some monitoring of the solution completion, even though we would claim victory when the solution implementers came to agreement. Monitoring doesn't have to be a high overhead thing. However, if you just throw this stuff over the wall, neither we nor our partners nor customers will necessarily know if the goals are actually achieved. "Slide 3 is a rehash of parts from #3 but uses different terminology, Problem Proposal vs Problem Statement. This is confusing." In my experience with standards bodies, it is important for people on the outside to clearly understand the status of an item -- whether it is in the initial stages or whether it is actually getting worked on. That is why I identified two separate terms for these two things. The Proposal can be anything coming from anyone without any formal status. It is just dumped into the issue tracker for consideration. When it gets to the stage of having a Statement of the problem, it has had work done on it and is being pursued by the workgroup to see if we can get it answered. " ....Also the Problem Statement can be formulated by anyone. If we are on the hook to do it, it'll never get done, lets be inclusive, not exclusive. We are not the elite of problem description writing ;)" Clarified. "The rest looks more like a rehash of #3 again. If #3 is not specific enough lets work on it rather than presenting the same info in 2 different documents." I agree that they should be merged. However, I did not have the time to redraw yours in an unfamiliar tool on short notice. The .dia font is also awful in the existing file with "solicit" looking like "soliat." "Also please remove you name, you get credit for your work in the log, what we publish should be from the work group, IMHO" Apologies -- I missed deleting my footer. Reposting a new workflow file in a few minutes. |
|
So lets all agree on a format then for flow diagrams! I am not particularly attached to the dia tool but it has a set of nice features that make things work. Arrows are attached to anchor points making it easy to move things around and keeping the arrows where they belong. The infinite canvas allows creation of flow diagrams without having to worry about page size limitations. The submitted diagrams are not working for me. Having arrows not connected, overlapping, and off the mark does not work for me, sorry. The problem about clarification of "Problem Proposal" as mentioned in my initial comment still exists. The phrase "Problem Proposal" is not used anywhere else, thus no one will have any idea what it is and how one is created. Based on the work that is pending in #3 and the accepted README.md file one expects pull requests for "Problem Statements", thus the work in this pull request is inconsistent with prior work. A "Problem Proposal" would be an issue filed in the Github issue tracker. The "Problem Statement" is tracked as described in README.md "The working copy of the Problem Statement is tracked in documents/problems." We already agreed to this, lets stick with it. Consistent wording is important. On slide 2 the flow does not provision for no solicitation of the "Problem Statement", there are cases where the problem may be glaringly obvious and one would want to move to a "Proposed Solution" immediately, thus soliciting the "Problem Statement" and the "Proposed Solution" at the same time. Slide 2 also has formatting issues, text crossing box boundaries, disconnected arrows and loose ends. This flow would also force us to keep accepted (by the distros) solutions in an "open state" until all distros that pledge to implement a solution have it actually implemented, this could be as many as 100 distributions. Therefore the implementation cycle could be years. Consider the Enterprise release cycle of 3 to 4 years. This is IMHO not workable. Consider the concept outlined in REDME.md and #3. Once distros agree to a solution the "document" moves to documents/specifications. As distros implement their solution the "Distribution Support" section of the spec is updated, with distro name and implementation date. This update becomes the responsibility of the distributions not the working group. We have less tracking work and do not need to keep things in an "open" state forever more. One can easily write a short script that loops over the specifications and extracts the "spec vs. distro support" matrix to present the information in a web page, if such summary information is desired. |
|
Apparently there are cross-platform issues with LO also for some platforms. I don't see the line disconnects and awkwardness you are seeing from the description above on SLED 11 SP3. It's clear we need something that does objects and not bitmaps, but neither Dia nor Libre Office seems to be adequate for all of us for a single instance. Other suggestions? (Or perhaps we do split them after considering the 4th paragraph below.) If we have all of the sections in the template including the solution, why can't the submitter just fill in as many of the sections as is appropriate? Then the decision points are just fast-tracked. Boxes in the flow are intended to have only the immediate relevant requirements in them as noted on the earlier comments, not exclusive lists of everything possible. I disagree with your statement that the flow would keep an item in an "open state" until implementation. We can declare whatever we define. As a practical matter, distros are popping up all the time (like the automotive one), so we will never have a complete list. We need some key players and their statuses to make the function "critical mass." I don't think that the distros will read through all of this repo and update the distro section when they do a new release if no one pokes them. The implementers may not even know where their requirements for a function came from. How do we know we are successful if we don't get feedback? This doesn't have to be a heavyweight thing, just what is useful to keep them honest and to see whether we are being successful in solving the industry problems. If we find we don't need it, we can always lighten the process later. We cannot make it heavier. Robert, I'm deciding that you and I have a basic audience difference. In order for a new Standard mechanism to be successful, it needs to be externalized, explained and widely sold. Having been in the startup of UNIX(R) International, this is a basic part of my worldview. We need to start addressing the external audience as soon as possible. Since most commercial ISVs do not use Git (yet anyway) and it is important for them to understand the process stages, I felt it was important to build that picture with language they could relate to. (That is also why I consider it a benefit to put the flow into page-sized chunks where it can be presented to and consumed by outsiders.) Your audience is the working group in the terminology from last week's meeting. Perhaps these should be different things. Then we just ensure that they map cleanly. Do we as a team want to stash external-oriented stuff into a different directory to avoid confusion or just postpone tracking it here? |
|
I understand the need to present things externally, and yes there are different audiences. However, if the workflow of things needs to be separated by audience then we have a different problem. If we cannot present 4 simple decision points to everyone without creating different diagrams that's a problem. Having different diagrams also presents different versions of the truth which means there will be inconsistency in no time, that is not acceptable, IMHO. As far as implementation is concerned, the implementors better know what they are implementing and why. If there is stuff going into a distro and no one knows why, there's a problem. Thus I do believe that people that end up working on any given implementation will add their distro to the specification when they are done. Will this be forgotten every now and then, yes, simply because it's not automated. But for the most part I believe people will add their info, especially if we come up with a nice web page that shows the data, which again will be easy to implement. Well, you can certainly disagree with my "open until forever" statement, but I know this, if I interpret it that way there will be others that fall into the same trap. |
|
My opinion, figures in this process should be in a form which can be pulled in to a "powerpoint" (used generically, not the specific product) when needed to present, but should not natively be in presentation format. I think Dia and Xfig can save them into such a format (for example, png) just fine. Meanwhile, I don't think "discussion is on github" should be a problem for anyone operating in this space any longer. They don't have to be using git natively for their products to be able to participate here. Windows and Mac even have gui github clients that let everything be done very simply. |
|
Comments consolidated for the last two responses. The simple decision points and boxes should have the same diagram shape. If we are truly solving the bad industry problems, the developers will have If others will interpret the statement as you do, Robert, that is exactly Mats, I started from the .dia and found that when it sprawled across pages I'm pretty tied up this week and next, so I will be less responsive. I have On Sat, Apr 5, 2014 at 3:31 PM, Mats Wichmann [email protected]:
|
|
"....The terminology that is inside of the boxes is more likely what we need to be audience-specific." I am not convinced about this. In any case the concept that is behind the terminology has to be consistent, which in this case #3 and this pull request are not. In this pull request a concept of a "Problem Proposal" is illustrated that is related with a pull request. However, as agreed on the last call "proposals of things to work on" should just be filed as issues in the issue tracker. Thus, there is no pull request. Therefore there is a basic disconnect, and I don't care who the audience is, having such a disconnect is wrong. "Architects for CA and BMC and probably IBM Software Group are less likely to take time to look on a web site when there is not even a certification, for its contents" Well they didn't look at our web site when there was a certification. Therefore, there is no change in behavior. I am not aware of any IBM application that is LSB certified, or compliant, or that any team at IBM SWG is using the LSB tools, SDK or app-checker. ".....I started from the .dia and found that when it ...." well the version of dia in SLE is 5+ years old...... Anyway, part of the point here is that we should be working together on the same stuff when we try to relay the same concepts, irregardless of the audience. If we cannot manage that and improve on each others work but rather created disjoint stuff, then the whole effort is not worth my time. |
|
Sorry if I misinterpreted part of the Problem Proposal thing. I was still looking for the earlier referenced four decision points. If there are three, I can eliminate the decision box. Since you seem not to be able to see the correct images, I can fix it and repost it instead of requesting a fork from you. Just to be clear, is your point that there is no decision point for recognizing something as important enough to be worked as a problem statement (or more), or that there is a decision point here with no accompanying "state change" in the repo? I thought one of the main points of this LSB reset was to try to facilitate progress for the ISVs since we were unsuccessful with them the last time. If we can demonstrate our value to them, we can have a shot at having them pay attention eventually. (Actually, there were IBM SWG teams whom we helped use the appchecker up to the end of 2008. We helped them read their journal files. They just never published anything externally.) I had pulled a newest Dia down before using it to try to be consistent. I did not use one already on the SLED system, so it wasn't just age; I'm apparently missing something. I also pulled the latest LO stable 4.1.5 down to SLED to try to see what you were seeing that was messed up in the slides. I did not see any problems. I did not try unstable. If some of us on the team see different levels of discussion as useful compared to what you personally are working on, is there a way to work together as a team instead of seeing "disjoint stuff" and wasted time? In something as large as a new "standard" process, no one person can cover everything that has to be done to make it successful. |
|
OK, a "Problem Proposal" is an issue in the Github issue tracker and of course a decision has to be made if a given issue is worth the effort to go an push it through "the system." But on slide 1 of this pull request you have a box with the following text: "Problem Proposal This is simply contradictory to what is written in README.md and got accepted into the repo. It is also inconsistent with #3. Only "Problem Statements", "Solution Proposals", and "Specifications" have pull requests associated with them. That's the concept conveyed in README.md. That of course can be changed but would then necessitate an additional differentiation in documents, as in documents/proposals. And the pull request would have to have an accompanying README.md update. We work together by improving on each others stuff. While I may have submitted the initial pull requests to get this off the ground that doesn't make the work mine, it is ours. Everyone has the opportunity to modify it and send pull requests to the repo. Note that I didn't just stick stuff into the repo just because I have commit access. When you submit a libre office presentation for something that has already a pending pull request and is similar in concept you do not improve on existing work but create disjoint stuff. I have no intention of "...covering everything..." part of the idea of moving to GitHub was to make it easier for more people contribute. |
|
Do we have contacts at ... wait ... better ... Can we engage people from CA, BMC, et al? |
|
I had pinged my contacts at some of the larger commercial software On Mon, May 12, 2014 at 1:09 PM, Rick Troth [email protected]:
|
|
Closing this. somewhat superseded by #18 plus we have no agreement yet on the best format for diagrams etc. |
No description provided.