In our group, we have to model the state "needs discussion" for Bugzilla.
Therefore, a custom RESOLVED - to be discussed status was introduced. The appropriate group of people searches for issues that have this sort of "resolution" status and discusses these offline.
In my opinion, this is not the proper way as the bug/feature clearly is not resolved if there still is need for discussion. This is also reflected in the standard life cycle of a bug. It is sort of misleading, as "needs discussion" items show up in your list of resolved bugs.
One way I can think of, would be to make a sort of "virtual user", representing the group that has to be involved in the discussion. This has the advantage, that one can search for the bugs easily. One could also setup a mailing list to notify the users.
I wonder how one can appropriately model this needs discussion state of a bug in Bugzilla 3.0.x. (And: what is the Mozilla-way solution?)
As with any software system there are a multitude of ways to address your need.
Before you start with mechanism it would be good to think about requirements.
Do you want bugs the need discussion to be counted as "open" still, or do you consider them "resolved". Do you even collect those types of metrics?
The requirements I derive from your question are
Don't want to see them in normal searches
Do want to be able to see them when looking explicitely
Need to be able to finalize the discussion, and "bring the bug back" to normal
Would like to notify people that there is a discussion to be held
Would like the bugs to not look like they are resolved
If those are really the requirements, and you don't care that "for discussion" bugs are showing up as resolved for metrics etc, then I think what you have is probably good enough, except for point 5.
Some other alternatives
Create a "Discussion" product (or component).
Create a custom lifecycle (I wouldn't recommend that though).
Assign to the "Discuss-me" group/user
Use a "super bug", and mark the bugs a blocking the "Discussion super bug"
Create a "discuss this issue" bug, and mark the bug as blocked by the discussion (this reflects reality the closest, but that doesn't make it the best option).
But, as I say, think about what you're trying to achieve first, and then choose the mechanism based on that. There are different trade-offs around the amount of bug-fiddling you have to do to make them all work :-).
Related
Working on testing a React component, I was reading the docs and found scryRenderedDOMComponentsWithClass. I'm having trouble understanding the function of this component because it's unpronounceable, so I don't understand how it's naming maps to a mental model of what it's doing. (There are a number of related names, such as scryRenderedDOMComponentsWithTag.)
What does the scry part of this method name refer to? Scary? Scurry? What concept is this name trying to illustrate?
Short answer
"Scry" in this context just means "find all". See this comment on ReactTestUtils.scryRenderedComponentsWithClass. It's a single word, not an abbreviation, and it's pronounced like "cry" but with an "s" at the beginning.
Longer (and nerdier) answer
Elsewhere in that same file, you'll see a reference to DOM.scry:
/**
* Todo: Support the entire DOM.scry query syntax. For now, these simple
* utilities will suffice for testing purposes.
* #lends ReactTestUtils
*/
zpao explains in a comment on a GitHub issue:
That's a reference to an internal Facebook module. It's basically querySelectorAll with fallback behavior for handling old browsers and special cases. It is pretty unremarkable and doesn't actually translate super well here (except maybe a scryRenderedDOMComponentsWithQSA or something, but meh). We're working on improving the testing in other ways so I don't think there's anything we really want to do with this right now.
jimfb takes it a bit further in another GitHub issue, explaining that the name is a reference to Dungeons & Dragons:
Back in the day, we had a bunch of D&D fans on the team.
For reference:
http://www.dandwiki.com/wiki/SRD:Scrying
http://www.dandwiki.com/wiki/SRD3e:Scry_Skill
https://en.wikipedia.org/wiki/Scrying
Historically, we've used scry to indicate a helper that finds a set of results. As the framework matures, we should start choosing function names based on what the functions actually do instead of fantasy words that have very little meaning to the typical developer.
Though I would agree that the word has very little meaning to most, it's worth noting that "scry" is a real English word:
scry
[skrahy]
verb (used without object), scried, scrying.
to use divination to discover hidden knowledge or future events, especially by means of a crystal ball.
Interestingly, according to the data from Google's Ngram Viewer, it seems that the word fell out of normal usage in the early 19th century and then wallowed in obscurity until the 1980s, presumably after D&D gained popularity:
So I can't say I object to jimfb calling it a "fantasy word", especially considering the kind of imagery my imagination conjures up when I hear it.
I have been fascinated by Minsky's "Society of the Mind" for now close to two decades. However, I just realized that I have not come across any general implementation of the model (and preferable an implementation that is accessible and in the open source).
I recently ran into this article by Push Sing (now tragically deceased, student of Minsky), http://web.media.mit.edu/~push/ExaminingSOM.html where he also notes that such an implementation does not exist.
I wonder if someone knows differently and if such a project or corpus of software does exist.
Note: I am aware of SOAR, ACT-R, Cyc, etc.
Thanks.
I think that Minsky's "Society of the Mind" model is more literature and aspirational than an actual model. It has lots of systems, information flows and controls, but there isn't anything that you could implement without doing a lot of invention. Once you put it all together, you'd have a big data flow network, but you wouldn't have any data, so you would then need to fill it with representations of facts, concepts, connections, and so on. Then you would need to figure some way of having inputs and outputs that are understandable.
Let's say you built it --- what then? There is no obvious way to test it. It's unlikely that you would suddenly get consciousness pouring out. The only way to drive new action would be to feed new input, but it's unclear what sort of output would result. Minsky would probably smile and say that the same is true of a human baby. But at least with children we have a good idea that they will being to exhibit some kind of intelligence beyond stimulus response.
Still, if you have the time, why not give it a try?
loosly coupled communication between viewmodels is a nice concept.
I have used Prism Eventaggregator as well as MVVM Light Toolkit's Messanger.
If the project grows I get alot of messages back and forth.
What is best practise of keeping track of my messages? Naming conventions? patterns?
etc...
How do you keep track?
I've found that there is a lot of value in providing a "Messages" namespace that contains your strongly typed messages. Keep in mind that well-defined messages will be more like contracts/DTOs - you want to maintain as much decoupling as possible, so dependencies should be kept to a minimum, otherwise the senders and receivers will both rely on common libraries. Sometimes this is necessary due to the nature of the message.
I think you'll also find that many messages may follow a particular pattern. Two common message patterns are what I'll call the Action and Command. Action is more of a "verb" and a "subject".
For example, you might have MessageAction that exposes T Target, and the action is an enumeration that indicates update, select, add, delete, etc. That's common and a generic message can wrap it, and your handlers listen for the generics that close the type they are interested in.
The Command is an Action that originates from somewhere and then applies an action to a target. For example, maybe you are adding a role to a user. In that case, your item of interest is the role, your target is the user, and your action is adding it. That can be a CommandAction.
Another common way to organize messages would be to implement a common interface or base class. It then becomes trivial to search for implementors in the project to determine where messages are being used.
Good question. Here are the solutions I've been using, but there are probably a lot of alternatives and haven't found any guidance on that.
One way is to define specific events that extend basic events : typical example when using prism is an extension of CompositePresentationEvent.
However, when having a large number of messages, it's sometimes useful to define what is a message. Usually it can be defined by a message header, some message attributes and an actual content. Then you can put these messages into your messagebus.
I've got a WinForms client-server app that displays various offers in a list. Every user (client) has a "rating". An offer consists of various data including a minimum and maximum rating. If a user's rating does not fall in that interval, he should not be able to take the offer.
Of course I could just perform some server filtering and send a list of offers prefiltered for each user to the client application. But that would surely, and rightfully, lead to confused requests "Why isn't this offer showing up? I know it exists, it shows up on [other user]'s screen."
How should I handle this? My favorite solution so far is to grey out the offer and add a tooltip "You can't take this offer because your rating is too high/low" while displaying greyed-out offers at the bottom of the list to leave the actually valid offers easily visible on top of the list.
A disabled option tells the user:
The action is possible.
Just not right now.
But the user can make it possible.
Unless there is some simple action the user can do to change his or her rating (e.g., by selecting some other controls in the same window), do not use disabling and do not show the offers. Disabling may confuse some users who will then hunt around the window for something to do to enable those offers. It’s a great idea to use a tooltip to explain disabled objects, but that’s not a standard and not all users will think to hover the mouse over a disabled option (Why should they? It’s disabled).
Including offers users can’t have, even when disabled, clutters your display, forces more scrolling, and distracts the users from the offers you actually want them to consider. Furthermore, showing unavailable offers can come across as taunting (“ha, ha, your rating isn’t high enough”) and may diminished the perceived value of the available offers by comparison, resulting in lower user satisfaction.
It seems unlikely to me that users are going to go around comparing the offers on their windows, but maybe you have user research saying they do. In any case, you should label the list of offers to make the criteria clear (e.g., “Offers available at your rating” may be sufficient).
If you want to encourage users to increase their ratings, then maybe include something advertising the benefits of an improved rating. For example you could have a link "-Improve your rating- by four points and get -five additional offers-." The first -link- tells users how to improve their rating, while the second lists the offers as a motivator. The latter link should only be there if the offers will still be available if the user actually succeeds in getting four more points.
That sounds like a good way to do it.
As a slight improvement, if it makes sense for your application, you might consider including the actual numbers in the tooltip, e.g.:
This offer requires a rating between 5 and 8. Your rating is 4.
Say I come up with some super-duper way of representing some data that I think would be useful for other people to know about and use. Assume I have a 'spec' in some form, even if it might not be a completely formal one: ie, I know how this file format will work already.
How would I then go about releasing this spec to get comments and feedback based on it? How would I get it 'standardised' in some form?
Specifying file formats is difficult. If the data you want to store is trivial, it tends to be trivial. In general however, this is hardly the case. You can use the RFC structure and keywords, but I always found specifying a fileformat in prose a slow, difficult and boring task, also because reading it is likewise difficult.
My suggestion, if you want to follow this way, is to focus on blocks of information. Most of the difficuly is for entities that are optional, and present only if another condition happens, so try to exploit this when partitioning your data.
The best spec, IMHO, is real code with an uberperfect testsuite.
As for standardization, if enough people use it, it becomes a de-facto standard. you don't need an official stamp for it, although when the format is used enough, you could benefit from an official mime type.
To talk about it, well, it depends. I found useful to talk in terms of "object oriented" entities, and also in terms of relationships. Database-like diagrams are very useful on this respect.
Finally, try to find a decent already standard alternative first, or at least try not to deal with the raw bits. There are a lot of perfect container formats out there that free you of many annoying tasks. The choice of the container depends on the actual type of file format (e.g. if you need encryption, interleaving, transactions, etc).
There are a couple of ways I'd go about it, I think.
First, determine if there's a standards body (like W3C, or IEEE) that might be related to your file format. If there is, pitch it to them. I have no idea how receptive they'd be though.
Second, a standard is useless if nobody is using it. Get some momentum behind it. Write a blog post, twitter and make a website about it. Link on programming.reddit.com, and slashdot. Describe it to your friends and colleagues. Post it here on SO, and ask for feedback.
HTH.