Closed afc163 closed 5 years ago
居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。
- 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
- 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了
这不是自相矛盾?
不会有说明 不符合预期的行为开发者自己想办法
开发者怎么在问题出现之前发现问题?
居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。
- 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
- 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了
你的用户是开发者,而不是我的用户,你绕过我给我的用户的彩蛋不叫惊喜叫惊吓
为这个彩蛋点赞!
居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。
1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。 2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但**甩锅**不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了
也就是说,以后用开源产品得通读代码了? 是不是下一步就要求所有类库「自主可控」,只能使用有国标认证和实名备案的类库。
居然没让产品经理出来背锅(手动狗头)
居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。
- 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
- 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了
你的用户是开发者,而不是我的用户,你绕过我给我的用户的彩蛋不叫惊喜叫惊吓
同意,绕过开发者直接给用户就是惊吓
创意是好的 出发点愚蠢的 过程是快乐的 结果是不负责任的 还是做金融场景的公司 安全感都给不了用户
@jamieYou 提个 issue 看看
创意是好的 出发点愚蠢的 过程是快乐的 结果是不负责任的 还是做金融场景的公司 安全感都给不了用户
不就是按钮上加了点雪花吗?这咋不安全了?
其实这件事影响这么大 还有很重要的原因是 楼主没有预测到国家刚好在近期禁止洋节 事业单位本因起带头作用的...
有想法是好的,但是在开源的产品中,信任最重要
惊喜变惊吓。。。
2. unexpected
彩蛋应该是对用户还说的,而不是对开发者!!!是否给用户彩蛋应该有库的使用者(开发)来决定;并且这么大一个开源库这么做只能说明愚蠢!
所以。。。这个时候怎么没人拿出 LICENSE 来看看???
https://github.com/ant-design/ant-design/blob/master/LICENSE
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
The software is provided "as is", without warranty of any kind, express or implied,
including but not limited to the warranties of merchantability,
fitness for a particular purpose and noninfringement.
In no event shall the authors or copyright holders be liable for any claim,
damages or other liability, whether in an action of contract, tort or otherwise, arising from,
out of or in connection with the software or the use or other dealings in the software.
评论都是人才
监督……
居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。
- 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。
- 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但甩锅不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了
这不是自相矛盾?
不会有说明 不符合预期的行为开发者自己想办法
开发者怎么在问题出现之前发现问题?
帅锅局
还是VUE好,楼上的各位大神,还是改用VUE开发吧。
来吃个瓜,哈哈~ 彩蛋还挺娱乐的~
antd本身谈不上责任,但确实有些项目不适用这个效果,开发人员毫无防御准备。to C的还好,to B的少不了需要跟客户解释等后续问题,还有部分政府项目或者宗教信仰不同的族群开发的应用。不过如果能配置也是不错。
用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。
如果客户也觉得屁大点事那就好了
如果把彩蛋交给开发者自由配置(自由配置时间和显示方式)就好了,这个还是有需求的。辛苦后续完善一下,给框架再增添的色彩。
用的时候没一个人说谢谢,屁点大而且本意并无任何不妥之处的小事就来问候辛苦的团队成员全家。
这话说的就很不妥,隔壁有个兄弟说的好,快渴死的时候给我一杯免费的水喝我很感谢,但在水里下毒就不对了。何况开源的核心绝对不是“爱用不用”。
最后是不是会冒出来一个 是临时工的关系
发来贺电
哈哈哈 还好我司做的不是政府项目 心疼被开除和扣奖金的兄弟
圣诞和你有啥关系,我们是中国人,这么典型的文化入侵为什么要舔,外国人过我们的春节嘛,吃我们的饺子吗,就是人家外企的圣诞气氛,也没国企的浓,加个圣诞,皮一下,就那么开心吗,那么开心吗,那么开心吗
居然这么多人义正言辞的反对,那作为支持者就要出来说话支持一下了。
1. 彩蛋本身就是不会有说明的。加了说明的那个叫特性不叫彩蛋。 2. 当遇到不符合预期的行为时,向社区反馈并积极协助当然是一个很好的行为。但**甩锅**不是。在patch出来前,或者如果这个unexpected behavior是by design的,那就需要使用者(在这同样也是开发者)自己去想办法修复或者绕过了
也就是说,以后用开源产品得通读代码了? 是不是下一步就要求所有类库「自主可控」,只能使用有国标认证和实名备案的类库。
我觉得可以有,很安全
大家都是开发者,可能觉得不会有什么问题或者不妥,但是我们把它应用到企业产品里面,这就很严重了。这样动态改变样式,让企业用户觉得是不是还有监听业务数据、会不会私自上传企业数据,这都很严重啊!
是在作死:
还是VUE好,楼上的各位大神,还是改用VUE开发吧。
ant-design有vue版本的兄弟
其实这件事影响这么大 还有很重要的原因是 楼主没有预测到国家刚好在近期禁止洋节 事业单位本因起带头作用的...
政府啥时候近期禁止过洋节了, 没看到这个消息, 我看你就不要再传谣了吧, 唉
已经被开了 感谢楼主让我提前回家过年 终于有时间好好陪陪父母了
你是真的皮
此issues可以作为检测贴..... 凡事支持这种彩蛋(or觉得没什么)的人都可以认为是如下的情况: 1: 单纯的蠢(确实不知道,这种人还有救). 2: 揣着明白装糊涂(这种人就是坏.).
可以试试Fusion Deign https://fusion.design/
有创意是好事。可以过一过咱们中国的传统节日。
不应该默认关闭吗,默认开启就有点流氓的感觉了
@chn-yang 你的消息来源真封闭啊
做为开源项目确实不应该,起码应该在文档中明确标注,并且默认关闭
可以作为feature支持,切忌动态生效啊
其实这件事影响这么大 还有很重要的原因是 楼主没有预测到国家刚好在近期禁止洋节 事业单位本因起带头作用的...
政府啥时候近期禁止过洋节了, 没看到这个消息, 我看你就不要再传谣了吧, 唉
是有的,不过没有公开说,我们这边大学很多都不让
码农和设计师的审美。。。。
@chn-yang 你的消息来源真封闭啊
呵呵, 拜托, 不要以谣传谣好吧, 什么时候禁止普通人过圣诞节了? 具体单位约束具体人我不想讨论, 对于那些普罗大众来说啥时候被禁止了, 有禁止都是你们单位的事, 请停止回复我
开源精神代表了要对自己的repo负责,既然项目会被其他的developer使用,类似彩蛋的东西应该广而告之并且由使用者来决定是否启用. 如果这次的style做成了可配置项,而且提前在changelog告知,那我觉得会是一件皆大欢喜的事情,结果现在搞成了教科书级别的作死...
where is tag 3.9.4, i can't found?
事情根本原因是在这个 feature 的考虑和 review 的问题吧。我觉得不是愚蠢,是不够谨慎而已。contributor 本身的初衷是好的,如果没有这种创新,哪有今天的的开源社区。但是,能力越大责任越大。Ant Design 本身具有非常大的影响力,作出任何修改,都要三思而后行。而且软件工程本身是一个迭代过程,有 bug 有错误决定都是过程上不可缺少的一环。KEEP GOING!💪🏻
贯高,哈哈,尼玛,感谢送彩蛋
别说了, 又是一个实习生搞的鬼, 已经被开了, 阿里的日常
关于 Ant Design 圣诞彩蛋,起源自 2018 年 9 月 10 日我的一次提交:https://github.com/ant-design/ant-design/commit/00aebeb9756afecc884ad48486084836b9a2707a 。代码实现会在 12 月 25 日当天给所有按钮添加积雪效果,并增加
Ho Ho Ho!
的浏览器默认提示信息。这完全是我个人的一意孤行且愚蠢的决定,是我的错误给大家造成了不良影响,非常抱歉。如何修复这个问题?
影响范围:
3.9.3
、3.10.0 ~ 3.10.9
、3.11.0 ~ 3.11.5
我们已经回滚相关代码并发布了修订版本:3.9.4、3.10.10、3.11.6,各位请更新至相应的版本即可。使用了语义化版本的直接重新安装 node_modules 并重新下载即可。
代码里还有其他彩蛋么?
没有。
未来还会有类似的问题么?
不会。我们是开源软件,请像这一次一样持续监督我们,你们的监督让开源社区更美好。