543 ideas match your query.:
Search ideas
This is the kind of thing that’s messed up and should be prevented: https://x.com/CatchUpFeed/status/1819079527366382071
There are financial incentives to do abortions as late as possible.
In activity feed, behind timestamp (‘… hours ago’), link to corresponding discussion.
As of 9702c05, a revision activity now says that the idea was either marked or unmarked as a criticism.
When a comment is a criticism on another criticism, the activity should say ‘So and so addressed criticism #…’
Superseded by #349. This comment was generated automatically.
The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms just like when they are child ideas.
Superseded by #344. This comment was generated automatically.
Should probably show the explanation in a revision, when given. In the activity feed, that is.
Highlight current nav item.
It doesn’t really matter. This would be like calling a controller action from a helper method. Not something people do.
The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms such like when they are child ideas.
Should I give the icons in the activity feed colors?
Should probably show the explanation in a revision, when given.
When all I change during a revision is the criticism flag, the activity log just says ‘no changes’.
Superseded by #335. This comment was generated automatically.
I think the thing I’m really fighting here is Rails being object-oriented. Which I can’t do anything about.
Not sure the Rails team realizes how much OOP reduces the extensibility of Rails.
I think the thing I’m really fighting here is Rails being object-oriented. Which I can’t do anything about.
Not sure the Rails team realizes how much OOP reduces the extensibility of Rails.
Having explored three different ideas, I believe #302 – having regular helper methods to render Hiccdown structures – is the best.
The idea is not without its flaws, but having to qualify a method name by, say, calling it idea_form instead of form is still better than manually having to pass the view context around all the time and not being able to trivially access instance variables.
So I’ll stick with #302 for now, which is the status quo already.