User talk:Dzonatas/Ethics and MediaWiki
I discovered that the ACM has a Code of Ethics for Software Engineers.
It's mostly about professional standards that would apply to almost any profession, but one section of their code relates to the software product itself...
Section 3 (of 8) reads as follows:
|“||Principle 3: PRODUCT
Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. In particular, software engineers shall, as appropriate:
3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are clear to and accepted by the employer and the client, and are available for consideration by the user and the public.
3.02. Ensure proper and achievable goals and objectives for any project on which they work or propose.
3.03. Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects.
3.04. Ensure that they are qualified for any project on which they work or propose to work by an appropriate combination of education and training, and experience.
3.05. Ensure an appropriate method is used for any project on which they work or propose to work.
3.06. Work to follow professional standards, when available, that are most appropriate for the task at hand, departing from these only when ethically or technically justified.
3.07. Strive to fully understand the specifications for software on which they work.
3.08. Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and have the appropriate approvals.
3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates.
3.10. Ensure adequate testing, debugging, and review of software and related documents on which they work.
3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work.
3.12. Work to develop software and related documents that respect the privacy of those who will be affected by that software.
3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized.
3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.
3.15 Treat all forms of software maintenance with the same professionalism as new development.
Moulton 01:56, 14 July 2008 (UTC)
- That is an excellent inclusion. I would also note this clause:
- "The Code is not simply for adjudicating the nature of questionable acts; it also has an important educational function. As this Code expresses the consensus of the profession on ethical issues, it is a means to educate both the public and aspiring professionals about the ethical obligations of all software engineers."
- Dzonatas 02:18, 14 July 2008 (UTC)
|“||In the five phases of the System Development Life Cycle (SDLC), you are a part of the audience that is addressed by the maintenance phase. You interact with the engineers (the scientists, or other liaison roles) that work together to improve the system. From your perspective in the maintenance phase, the rest of the SDLC cycle may appear opaque to you, yet it is considered the last phase of the cycle. Once feedback is gathered from you the cycle continues; the engineer's restart in the analysis and planning phases. If there is no feedback gathered or the feedback is too improper, the cycle ends; the system development comes to a standstill.
If the cycle ends, those left to manage the wikis have to make do with the tools they have available. Further, if trouble arises when there is no mechanism for feedback, people are left to place blame on others where they don't work well together or with what is available, and that course of action , the blame game, may not be the best ethical solution. When it is the engineers themselves that get blamed in such course of action, and they are do not get feedback because they are being ignored, it becomes much harder, if not impossible, for them to research how to improve the system. Remember that it is the software that is the medium for which the community engages each other. If that medium fails, communication fails. This is where we learn how to bridge the digital divide.
This paragraph is in need of rewriting. WAS 4.250 04:25, 14 July 2008 (UTC)
- I made changes to paragraph above before I edited the resource page. I'll move it in if no objection. Dzonatas 08:04, 14 July 2008 (UTC)
- No objection from me. WAS 4.250 08:09, 14 July 2008 (UTC)
- Should the pronoun "you" be replaced by a nominative such as "the software developer"? The phrase "the engineer's restart in the ..." doesn't sound right. Should that be "engineers" (plural) rather than "engineer's" (possessive)? —Moulton 20:35, 14 July 2008 (UTC)
- I fixed it to "engineers" on the resource page. As for the usage of "you," it is the reader, the sysop, or the aspiring sysop (the one taking the course, see Ethical_Management_of_the_English_Language_Wikipedia/Project_Timetable#2009). I thought about a section to describe roles, but that step may be too soon if it is really needed. Dzonatas 22:31, 14 July 2008 (UTC)
I still don't know what those two paragraphs are supposed to be saying but let me try to rewrite them so the sentences at least parse into something grammatical with meaningful semantics...
|“||In the five phases of the System Development Life Cycle (SDLC), software developers are key participants in the maintenance phase. Software developers interact with the systems engineers (the scientists, project managers, or other liaison roles) who work together to improve the system. From the perspective of the software developer focusing on the the maintenance phase, the rest of the SDLC may appear remote or opaque, since maintenance is final phase of the cycle. But feedback from the maintenance phase can cycle back to the analysis and planning phases for the next generation of the system. Without good feedback from the maintenance phase, development of improved versions may be stymied.
In the absence of evolutionary software enhancements, operators of the system may be left with obsolete tools. When an insufficiently maintained system degrades over time and becomes progressively more dysfunctional, there is a tendency to place the blame on individuals rather than on systemic failure. Diagnosing and resolving systemic weakness is thus an important professional ethic, to avoid an overall loss of morale in the wake of a progressively failing system. Since the MediaWiki medium is also used for communication among the project teams, it's important to preserve that essential communication service at all times, to avoid a catastrophic cascading failure.
I dunno if that's what you want those two paragraphs to say, but at least the above demonstrates something that I would understand.
Moulton 02:43, 15 July 2008 (UTC)
- If you swapped "software developer" out and replaced it with "operators" (or "system operators") in the first paragraph, then you will be closer to the intended perspective. Dzonatas 03:13, 15 July 2008 (UTC)
- Well that's fine. Go ahead and plug in whichever project roles belong in each instance, so that the cast of characters is properly sorted out. Then let's see if the semantics still make sense. —Moulton 03:22, 15 July 2008 (UTC)
- Based on your feedback there, I can see how the concepts of the semantic web confuse the perspective. The semantic web is only of historical concern, as it has not been practical in whole. Engineers now use concepts of highly distributed models. I'm sure, given time, more details can be added here that will help understand this resource more. Dzonatas 16:00, 15 July 2008 (UTC)
- I agree. I think I see where you are going with this. It appears it just needs to be fleshed out more. And by the looks of the red linked subsub-pages, it appears you are going to do just that. So keep up the good work! WAS 4.250 16:24, 15 July 2008 (UTC)