#1 - 2015-9-1 14:54
Sai (Awesome!)
随着年世渐高,日常业务繁忙,投入到 Bangumi 开发的精力越来越少。而 Bangumi 的架构愈发庞大,待完善功能繁多,项目逐渐陷入一年只有一两个新功能,停滞不前的境地。

键者开始思考如何能集社区之力进行功能开发的方案。

相比一人开发,多人开发存在沟通和管理成本,包括代码的管理维护部署也会有障碍。

如果决定社区化开发,代码数据库的安全性,如何选择开发人员也是问题。我希望尽量维持一个精简的 3-5 人团队来进行这件事情。

大家有什么想法?
#2 - 2015-9-1 15:10
(miaow~~~)
@upsuper 你觉得呢 ... (bgm37)
#2-1 - 2015-9-1 15:15
SuNNy
第一个提名的肯定是www
#2-2 - 2015-9-1 17:08
upsuper
不幸的是最近忙得很 /_\
除了公司的项目以外,我前两天还刚刚作死挖了个新坑最近压力颇大……
#2-3 - 2015-9-1 17:15
MousHu
upsuper ‏ 说: 不幸的是最近忙得很 /_\
除了公司的项目以外,我前两天还刚刚作死挖了个新坑最近压力颇大……
到处宣传 一回国就被请喝茶 ~ (bgm48)
#2-4 - 2015-9-26 18:42
upsuper
啊最近之前在做的东西稍微告一段落了,不过新坑一行代码都还没开始动,总之也许稍微有些时间可以参与。如果多是一些小功能/小bug能用来填塞什么都不想做的时间就最好了(
#3 - 2015-9-1 15:17
(夜海全书)
以目前bgm庞大的体量,至少需要5个人吧。
#3-1 - 2015-9-1 17:47
lhb5883-污喵王VIP⑩
其实我觉得不需要,能力足够的话,人越少越好。
#3-2 - 2015-9-1 17:49
Doream
lhb5883 说: 其实我觉得不需要,能力足够的话,人越少越好。
如果是全职的话,显然3个就好。但显然bgm不会商业化运作。
#3-3 - 2015-9-1 18:21
名雪
四个够了应该…
#3-4 - 2015-9-1 18:30
Doream
田所浩二 说: 四个够了应该…
真要做好的话,好多地方得大改……
#3-5 - 2015-9-1 18:36
名雪
Doream 说: 真要做好的话,好多地方得大改……
讲真,这个新团队干脆直接开工重构
想了想业务逻辑不是很复杂,用成熟的框架重构的话也不会花很久
#3-6 - 2015-9-1 18:37
Doream
田所浩二 说: 讲真,这个新团队干脆直接开工重构
我也这么认为(要是我学开发的话
#3-7 - 2015-9-1 18:38
名雪
Doream 说: 我也这么认为(要是我学开发的话
σ`∀′) ゚∀゚)σ 快加入我大RoR神教啦~~
#3-8 - 2015-9-1 20:03
Doream
田所浩二 说: σ`∀′) ゚∀゚)σ 快加入我大RoR神教啦~~
我连这个职业都不是(一朝入错行,十年来补偿……(bgm38)
#4 - 2015-9-1 15:23
(Enjoy your (real) life!)
虽然有很多爆炸性的想法,但是我想最优先要说的是这个事情不要以一种民主化的方式决定,以防又出现上次那个一起做游戏的烂尾。
晚上再来填坑
#4-1 - 2015-9-1 20:31
luna
加一
#4-2 - 2015-9-1 21:25
海卫四
deon.W. 说: 加一
你这让楼主怎么填坑(bgm38)
#4-3 - 2015-9-1 21:42
豆沙包罐头
不得不承认,这种情况下集权更有效率
#4-4 - 2015-9-1 22:04
Genius、小乖
坑在 39 楼。
#4-5 - 2015-9-1 22:43
塔塔塔
+1,这种问题最好不要争取群众的意见…
#4-6 - 2015-9-5 20:45
fantasy
嗯,都是我的错。
#4-7 - 2017-7-3 23:56
everpcpc
小乖每次都能说到点子上
#5 - 2015-9-1 15:39
(大破的那珂酱好萌!)
默默围观。虽然不是码农但如果能做些什么会帮忙的。
上次和大水比exp聊到了完善drrr聊天室的事,也许以后可以做了
#5-1 - 2015-9-2 09:39
Explorare Nota Seniorious
为什么是大水比啊(bgm38)我确实想做个bgm的drrr,带私密房间的,能干一些奇怪的事(bgm38)
#5-2 - 2015-9-2 09:59
板砖加身
Explorare 说: 为什么是大水比啊我确实想做个bgm的drrr,带私密房间的,能干一些奇怪的事
啊,这几天没水,小水笔吧。。。。
你倒是去要源码看啊
#5-3 - 2015-9-2 10:00
Explorare Nota Seniorious
板砖加身 说: 啊,这几天没水,小水笔吧。。。。
你倒是去要源码看啊
好的
#5-4 - 2015-9-2 10:20
Explorare Nota Seniorious
板砖加身 说: 啊,这几天没水,小水笔吧。。。。
你倒是去要源码看啊
https://code.google.com/p/drrr-like-chat/
#5-5 - 2015-9-2 10:38
板砖加身
Explorare 说: https://code.google.com/p/drrr-like-chat/
看过。。。
我找了半天发现能用的是萌否一个程序媴(直觉?)fork的版本https://github.com/xi4oh4o/dollars-pages
其他的貌似无法建立房间,也许我的环境有问题?
#5-6 - 2015-9-2 10:42
Explorare Nota Seniorious
板砖加身 说: 看过。。。
我找了半天发现能用的是萌否一个程序媴(直觉?)fork的版本https://github.com/xi4oh4o/dollars-pages
其他的貌似无法建立房间,也许我的环境有问题?
所以之后等开发的时候还是要找那边站长忙帮指导一下。
#5-7 - 2015-9-2 10:55
板砖加身
Explorare 说: 所以之后等开发的时候还是要找那边站长忙帮指导一下。
是的。我倒是弄了一个 drrr
css被我搞乱了,还没修
#5-8 - 2015-9-6 21:57
fantasy
Explorare(id: explorare) 说: 为什么是大水比啊我确实想做个bgm的drrr,带私密房间的,能干一些奇怪的事
我倒是希望超展开能够分离。
#5-9 - 2015-9-6 22:12
Explorare Nota Seniorious
fantasy 说: 我倒是希望超展开能够分离。
最起初的想法是,有些闲话专门开个楼挺无聊的,另外,现在的回复系统太反人类,不能自动刷新,每次刷新都得重载整个页面包括图片,不能自动折叠楼层,不支持Markdown和代码高亮,不支持chrome的桌面提醒特性,现在用别的插件监控https://bgm.tv/notify 的变动才能及时回复。而且不能高亮所有新回复,有时候多人回复的话点进去只会高亮最底下的,比较烦。
#5-10 - 2015-9-6 22:19
fantasy
Explorare(id: explorare) 说: 最起初的想法是,有些闲话专门开个楼挺无聊的,另外,现在的回复系统太反人类,不能自动刷新,每次刷新都得重载整个页面包括图片,不能自动折叠楼层,不支持Markdown和代码高亮,不支持chrome的桌面提...
嗯,然后呢。
#5-11 - 2015-9-6 22:24
Explorare Nota Seniorious
fantasy 说: 嗯,然后呢。
所以我希望能有两个改进,一个是增加更有效的提醒系统,另一个是改进现有编辑器,增加代码高亮和Markdown支持,要是能支持自动刷新和部分刷新功能就更好了(虽然可能这个是最好实现的)。
#5-12 - 2015-9-7 00:02
板砖加身
Explorare 说: 所以我希望能有两个改进,一个是增加更有效的提醒系统,另一个是改进现有编辑器,增加代码高亮和Markdown支持,要是能支持自动刷新和部分刷新功能就更好了(虽然可能这个是最好实现的)。
自动刷新可以用ajax实现,而且现在的评论提交也是ajax吧
#6 - 2015-9-1 15:42
萌否的做法是通过面试同城面基来增加人员的靠谱性(大概). 园长应该有经验.
#7 - 2015-9-1 15:46
(据说这是个婚恋网站我就来了)
有开发团队的话,还望有个学习位置(bgm70)
#8 - 2015-9-1 16:08
(この身はそなたの“剣”──そう誓ったはずだ。 ... . ...)
感觉一大片的那什么正在逼近(bgm105)
#9 - 2015-9-1 17:02
(不要停!)
好!同意四楼,不过精简化的团队内部也不存在民主化的决定方式吧。
#10 - 2015-9-1 17:09
(随性和严谨比较起来的话,果然还是随性一点比较好 ... . ...)
务必要有邪恶的理事会和理事长(bgm24)
#11 - 2015-9-1 17:30
(平行)
搬小板凳前排围观。
#12 - 2015-9-1 17:40
(絶望した)
期待进展
#13 - 2015-9-1 17:40
(Viro kaj virino. Popolo distingas ni en du tipoj.)
PHP 的話我可以 (bgm38)
#14 - 2015-9-1 17:42
(Viro kaj virino. Popolo distingas ni en du tipoj.)
首先Sai 開個 Slack 吧 (bgm38)
#15 - 2015-9-1 17:46
(媛娇系是检验大法的唯一标准)
选一个主程或者架构师,全权负责,当然SAI的决定权也是很重要滴。
#16 - 2015-9-1 17:50
(媛娇系是检验大法的唯一标准)
另外不是年事已高么?

难道是年事以糕的缩写?“bu年neng糕ti伯de爵ren的事已经不能再糟糕……”
#16-1 - 2015-9-1 18:41
名雪
KY点
#16-2 - 2015-9-5 20:46
fantasy
哦?华点?
#17 - 2015-9-1 17:56
(萌え萌え~)
搜索功能完善一点就好了,偶就会CSS,JS,外加一点PHP
#18 - 2015-9-1 18:08
说来我记得谁有整理维护个希望有的功能列表来着?好像是 @林卯
#18-1 - 2015-9-1 20:18
#18-2 - 2015-9-1 20:32
糸色企鹅
小组:今天也没有
#19 - 2015-9-1 18:14
(困…)
好事,虽然我的水平大概帮不上什么忙(bgm38)
#20 - 2015-9-1 18:15
(2011 冬、始)
先看看=。=
#21 - 2015-9-1 18:20
(世界の殼を破られば、我らは生まれずに死んでいく ... ...)
围观一下(bgm24)我倒是觉得现在这样就挺好……
#22 - 2015-9-1 18:28
然而好像并不能成为战斗力的样子 (bgm38)
#23 - 2015-9-1 18:43
(ハロ/ハワユ)
大学开学就要学做码农的我……还是先前排仰望一下菊苣们好了。
#24 - 2015-9-1 18:53
(宛在水中央)
放权好,不过sai语录最好还能用,有些争议还是需要sai的决策
#25 - 2015-9-1 19:29
(万物非主,惟有真主。)
有生之年,无力相助
#26 - 2015-9-1 19:38
好支持顶,最好选择一些有精力有毅力的人。
#27 - 2015-9-1 19:46
正好趁着个机会提个问题。
由于Bangumi的词条覆盖性很全面,甚至包括了一些限制性内容。我个人倒是挺喜欢Bangumi能收录这些信息这一点的,但一直以来我对推广Bangumi抱有担忧,担心随着Bangumi的发展,这个网站会被要求删掉那些内容或被屏蔽。恐怕决定那些内容的去留是这个网站发展壮大的道路上无法避开的决定,所以在这里想问一下Sai老板是怎么看这个问题的。
又:去年swift发布后,我尝试过用其实现了一个Bangumi的iOS客户端,用来追新番每章的评论。当然出于bangumi api 的不完善,以及上述担忧,我并不准备发布这个客户端。如果保持低调可以避开风险,没有移动客户端并不是无法克服的问题。
#27-1 - 2015-9-1 20:38
BinotaLIU
凭什么要求 Bangumi 删除内容

网路是自由的,又不受你国的政治审查
#27-2 - 2015-9-1 21:16
ainopara
BinotaLiu 说: 谁,凭什么要求 Bangumi 删除内容

网路是自由的,又不受你国的政治审查
我挺喜欢现在bangumi上新番的讨论氛围。感觉就像早期知乎一样。后来知乎变火了,但上面的内容也水了很多。所以只从用户质量的角度来说,也需要考虑这个决定未来发展方向的问题。Bangumi的开发加速,不是坏事,但是否能处理好改进带来的用户增长,以及用户增长带来的新问题,可能会影响到Bangumi的存续。这是我担心的问题。
#27-3 - 2015-9-1 22:02
Sai
ainopara 说: 我挺喜欢现在bangumi上新番的讨论氛围。感觉就像早期知乎一样。后来知乎变火了,但上面的内容也水了很多。所以只从用户质量的角度来说,也需要考虑这个决定未来发展方向的问题。Bangumi的开发加速,不...
按 roadmap 完善功能而已,用户不会有爆发性增长。
#27-4 - 2015-9-1 22:22
ainopara
Sai 说: 按 roadmap 完善功能而已,用户不会有爆发性增长。
那我就放心了,是我想多了。
#28 - 2015-9-1 19:48
(没有耐心的"观众"们...浮躁得过分 ...)
没有异议
#29 - 2015-9-1 19:50
(✨️VIP 8✨️)
前端开源供pull request,开通vip测试用户,后端......日后再说,先把简单的,能用userscript修复的问题修了,顺便磨合团队,筛选人才,浏览器就能看得代码也没有什么安全问题,不要想一次就搞个重构什么的大新闻(bgm27)
#29-1 - 2015-9-1 20:34
R
全楼也就这一条回复有点价值
#29-2 - 2015-9-1 20:38
小寒
我就知道会有膜蛤
岛沉不可避
#29-3 - 2015-9-1 20:39
BinotaLIU
能用userscript修复的问题修了
都给发 PR 了还用 Userscript 么 (bgm38)

---- Edited
好象是我没看懂你的意思:
如果是能用 Userscript 就能解决的问题,那就修了吧
这样么

其实用起来感觉更多功能需要在后端上做,
Userscript 能做的功能目前都有人做了 (bgm38)
#29-4 - 2015-9-1 20:59
Sai
重构短期内不考虑,不过老代码的前后端架构不利于维护和部署。

比如 JS CSS HTML 都是纯手写,一直考虑切到 LESS 之类的。
#29-5 - 2015-9-1 21:07
BinotaLIU
Sai 说: 重构短期内不考虑,不过老代码的前后端架构不利于维护和部署。

比如 JS CSS HTML 都是纯手写,一直考虑切到 LESS 之类的。
Bangumi 現在有 svn?
倒是向請 sai 大大搞個沙箱條目來用,
不計入條目編輯動態的,
有時候想測試一些東西比較方便

個人的想法也是贊同前端先做,
後端架構也可以同時進行,但是不立即部署。
我在樓上說後端不夠是因為有時候後端吐的資料不是我要的,在前端上用 Script 自然難做
#29-6 - 2015-9-2 00:36
名雪
这项目从08年开始,历史包袱可想而知
有读懂老代码的时间我肯定重构,反正业务逻辑也不复杂
#29-7 - 2015-9-2 01:01
若卡
田所浩二 说: 这项目从08年开始,历史包袱可想而知
有读懂老代码的时间我肯定重构,反正业务逻辑也不复杂
naive,你以为重构的时间会花在写业务逻辑上? (bgm38) RoR就是渣渣不服来战!
#29-8 - 2015-9-2 12:41
名雪
若卡 说: naive,你以为重构的时间会花在写业务逻辑上?  RoR就是渣渣不服来战!
愿意维护老代码的是真爱。我不想趟这浑水(bgm38)
#29-9 - 2015-9-2 13:27
BinotaLIU
田所浩二 说: 愿意维护老代码的是真爱。我不想趟这浑水
老代碼是 PHP ,要維護也不能用你家的 Rails
#30 - 2015-9-1 20:01
(原来bgm有这么多人)
请按照基本法来。。。
#31 - 2015-9-1 20:23
(汝视视汝)
(bgm67)不會php  nodejs要不要
可以做個API啥的..
#32 - 2015-9-1 20:37
支持一下,虽然觉得bgm就一直保持现状也够用了。
#32-1 - 2015-9-1 21:44
豆沙包罐头
右上角的头像偏移修好就够用了
#33 - 2015-9-1 20:56
好好不赞成,总觉得会有不好的事情发生(呸呸呸呸呸)。为什么bangumi 一定要那么完美,慢慢来就好了~
#33-1 - 2015-9-1 21:18
Genius、小乖
赞同好好的话,因为很少有技术人员考虑到文化层面的事情。
#33-2 - 2015-9-7 08:13
lighthouse
Genius、小乖 说: 赞同好好的话,因为很少有技术人员考虑到文化层面的事情。
总算是知道为什么专业课上学东西时总要我们顾及到最麻烦的社会文化层面了。
虽说我不是技术人员
#34 - 2015-9-1 21:11
(Viro kaj virino. Popolo distingas ni en du tipoj.)
這麼說來最近 osu 也要開源了,
Client 跟 Server 都是,
網站用的 Laravel (bgm38)
#35 - 2015-9-1 21:55
(谁再分不清©和代理的区别就打烂他的狗头 ...)
数据库别爆就行了  

然后是经验谈 这种参与的人越少越好
#36 - 2015-9-1 21:56
(あなたの傷は私の食べ物)
rubyist纯围观
#37 - 2015-9-1 22:00
(头像是河马。)
支持
#38 - 2015-9-1 22:02
(Enjoy your (real) life!)
嗯,有人可能会批评我说不专业,我对此完全赞同。因为我确实不是 Geek 精神那么强烈的人。我到现在也才敢在简历上声称我熟练使用两种语言而已。我并不想从技术方面考虑社区化开发会有什么影响,技术比我在行的人楼上多得是。
我所感兴趣的,是网站的技术对网站文化有什么影响。幸运的是,Bangumi 一直都保持了讨论的高质量,而且贴吧化衰落得也没那么快。这一切都功归于网站都保持最核心也是最简单的功能:点格子,评论,打分,而且不能读,也许偶尔会有几个惊喜(Dollars,Magi)。任何人都可以自由地对她/他喜欢的作品表达自己的理解。就这么简单,而不是一个全家桶式的服务。这正如一个雨季少女,尚未展示出她的成熟的火辣,令人充满遐想。
但是网站任何一个微小的改动,都有可能破坏这种文化。挂人城墙是一种很不好的行为。如果我哪一天在一部作品的吐槽箱里面评论的时候,还要考虑我的朋友会怎么评价,别人看到会怎么评价,为了政治正确我应该怎么评价,为了获得更多的赞我会怎么评价,这个网站无疑让我对它的吸引力大打折扣。而不幸的是,近年来似乎出现了这样的苗头。我为了一个吐槽箱的政治不正确评论还要在讨论版里跟人吵一架?要是真有这么一天我还是离开吧。
然而技术人员可能不会考虑到这些。一旦有人提出这些需求,这些需求将很容易实现。对于这些人来说,Bangumi 又不是他家,而他又通过实现一个吐槽箱的评价提升了自己的技术能力,又满足了 waiting list,何乐而不为?
为什么我更喜欢一个独裁的 Bangumi,因为什么样的人就会做出什么样的 Bangumi,保持了网站文化的一致性。然而一个团队的话,给出一个 waiting list 一条条实现,这些需求是每个人对 Bangumi 不同的理解,使得 Bangumi 的核心偏移,网站也会逐渐吸引到更多不同的人群,破坏目前的网站文化。
当然,有人会批评我说文不对题:Sai 大要的是减轻代码的负担,你给我扯这些没用的东西干嘛?对不起,我还是坚持我的想法:有什么样的人,就会做出什么样的东西。社区化,不是我们经常在技术宅小组里面看到有趣的东西就是时机成熟的了。
#38-1 - 2015-9-2 00:36
@chu2story
我想既然sai老板发了这贴肯定有所考虑
关于网站文化这方面……我觉得只有改前后提建议发声音了,像是挂城墙这样的“人际关系”类总不可通过代码阻止,但是如你所说的点赞等功能给网站带来的影响却总是可以的。
如果真有所顾虑,而sai老板的社区化开发又势在必行,那么我想建立一个用户与sai老板、与开发组之间顺畅的交流就有所必要
如果真是这样或许应该算在sai老板所说的“沟通和管理成本”上(笑)
另外我想就算是有所偏移也应该不会偏移到多远,既然sai老板是在这里招人社区化开发,那么我想bgmer总不会把自己的网站往臭了写,更何况他们愿意贡献代码
#38-2 - 2015-9-2 01:02
糸色企鹅
其实不一定是开发...我觉得主要是wiki系统这边,权限的完善之类的东西(
#38-3 - 2015-9-2 03:29
woozy
我觉得 Sai 老板能做出 Bangumi 很厉害, 即便平时较少管理和更新, 也依然能勃勃生机, 记得之前还有人发帖觉得 Bangumi 太好了想给 Sai 老板打钱. 可能是 Bangumi 整体太优秀了, 即便有一些小 bug 一些不便的地方, 用户也能忍受下来没有影响黏度. 然而不便就是不便, 我的 Google Keep 里还专门有张表来罗列我觉得不够的地方, 能做得更好为什么不做呢. Sai 老板自己没时间, 让靠谱的人来修修 bug 有何不可. 有开发团队后可能会开始受理用户的建议, 然而新功能做不做肯定要 Sai 老板拍板, 这并不影响 Bangumi 的独裁. 我觉得以 Sai 老板的产品能力不必担心功能上的改进会影响文化层面.
#38-4 - 2015-9-2 08:58
Genius、小乖
糸色企鹅 说: 其实不一定是开发...我觉得主要是wiki系统这边,权限的完善之类的东西(
Wiki 是一个比较中性的东西,对 wiki 修缮我没什么意见。
#38-5 - 2015-9-2 09:07
Genius、小乖
woozy 说: 我觉得 Sai 老板能做出 Bangumi 很厉害, 即便平时较少管理和更新, 也依然能勃勃生机, 记得之前还有人发帖觉得 Bangumi 太好了想给 Sai 老板打钱. 可能是 Bangumi 整体...
主要还是担心新的技术团队可能对自己的想法过于自信,不要说那些一开口就是“重构”的人了,那种工程师认为自己是正确的,我就要证明你是错误的的那种文化会对 Sai 的决策造成影响。希望 Sai 还是要做好心理准备啊。
#38-6 - 2015-9-2 09:08
Genius、小乖
妄想奇行Otaku 说: 我想既然sai老板发了这贴肯定有所考虑
关于网站文化这方面……我觉得只有改前后提建议发声音了,像是挂城墙这样的“人际关系”类总不可通过代码阻止,但是如你所说的点赞等功能给网站带来的影响却总是可以的。
...
有可能技术团队没意识到自己在把网站往糟糕的地方写,正如做推荐系统的人不会意识到用户认为推荐系统在嘲笑他们的品味一样。
#38-7 - 2015-9-2 13:17
@chu2story
Genius、小乖 说: 有可能技术团队没意识到自己在把网站往糟糕的地方写,正如做推荐系统的人不会意识到用户认为推荐系统在嘲笑他们的品味一样。
所以说需要一个交流啊
另外sai老板在#23-7、#40里提到了只是按照roadmap开发,就是说bgm城市建设规划还是按照sai老板之前的规划走
可以说还是开明专制ww
#38-8 - 2015-9-2 13:25
BinotaLIU
Genius、小乖 说: 主要还是担心新的技术团队可能对自己的想法过于自信,不要说那些一开口就是“重构”的人了,那种工程师认为自己是正确的,我就要证明你是错误的的那种文化会对 Sai 的决策造成影响。希望 Sai 还是要做好心...
重構遲早需要,但不是說功能,是指代碼結構,目前的代碼不易維護,
不過我是完全不贊成直接砍掉重練,不贊成換語言重寫,不贊成換 No SQL
#39 - 2015-9-1 22:02
无能为力,表示期待
#40 - 2015-9-1 22:12
(Awesome!)
一起开发是按着既定的 roadmap 来进行。

一方面有一堆 bug 需要修理,另一方面有一堆半成品功能的完善和改进,之后才是新功能的开发。

产品上我肯定会参与和掌控,所以说存在沟通和管理成本。
#40-1 - 2015-9-2 00:22
林卯
完全没提美术改进……
比方说我觉得头像右侧那个气泡回复图标实在有些——不明白这形状是怎么画出来的。
#40-2 - 2015-9-2 14:03
Sai
林卯 说: 完全没提美术改进……
比方说我觉得头像右侧那个气泡回复图标实在有些——不明白这形状是怎么画出来的。
设计 Bug 也算 Bug。

这得问 Fw 为什么缩放之后变成这鬼样了……
#40-3 - 2015-9-2 20:21
林卯
Sai 说: 设计 Bug 也算 Bug。

这得问 Fw 为什么缩放之后变成这鬼样了……
2种可能:
Fw新版有个“渲染矢量到整数像素(我的理解)”功能,所以……。
Fw的一些缩放操作会挪动路径点使其总是放在整数像素位置上,我研究为什么矢量图缩小再拉大到原尺寸会变形时发现了这点。

所以在画这图标时一开始就应当在15×15(或其整倍数)的画布里画,而非画完了再缩小。你说我上次画的图标“过于锐利”就是这样画的。
#41 - 2015-9-1 22:14
先拿python+mongodb重写?(bgm38)
#41-1 - 2015-9-2 02:08
饭团
附议。
#41-2 - 2015-9-5 20:49
fantasy
哈哈哈。
#42 - 2015-9-1 22:28
(狡兔三窟)
没人吐槽年事已高?

GITHUB搞个权限控制代码迭代如何

有权限的贡献。

方便管理。
#42-1 - 2015-9-5 20:49
fantasy
因为没有人相信年事已高。
#43 - 2015-9-1 22:49
(Hacking to the Gate)
对啊,吐槽年事已高的人好少(bgm38)
话说 Sai大 准备好供分享的资料了么?比如部署流程、API 文档之类的
前端开源我觉得不好,考虑到现在没有代码广告党还一批一批的,开源了还不定成什么样子
可以考虑用 Bitbucket,只有委员会成员才能接触代码,搞好 code review,部署要方便回滚

也许是今天晚上心情有点灰暗,我觉得前端开源之后肯定有不少山寨站出现,然后趁着热乎劲儿人一批一批地走了,最后 Bangumi 没有人再贡献新内容就荒了,其他的山寨站玩一票也荒了
不过这话说得好像我就有贡献内容似的
#43-1 - 2015-9-2 10:14
BinotaLIU
好像沒說要開源啊……再說前端什麼的不用開源也很好山寨
#43-2 - 2015-9-2 12:42
名雪
ˊ _ >ˋ 怎么可能开源啊,想太多(
#44 - 2015-9-1 22:58
工作好忙,没完没了的(bgm38)
自己没空,只能让信得过的有能力并且有兴趣的人来代劳了

上面说的开新坑直接重构也不错,能考验团队合作,过了这道坎,啥顾虑都没有(bgm88)就是累(bgm38)
#45 - 2015-9-2 00:20
(梦想仍然是成为像sac-自那样的脚本家w)
如果看得上的话请分我些测试(我也就会这个了
#46 - 2015-9-2 02:07
并不喜欢 php

=。=
#46-1 - 2015-9-2 06:09
upsuper
明明是世界上最好的语言(
#46-2 - 2015-9-5 20:50
fantasy
upsuper ‏(id: upsuper) 说: 明明是世界上最好的语言(
+1
#46-3 - 2017-7-3 23:54
#47 - 2015-9-2 02:10
不过我希望先 redesign 一下... 目前这个 UI 风格实在是有点.. 厌倦了...
#48 - 2015-9-2 07:39
+1
就算共同开发,什么代码能merge还是sai老板说了算的嘛,所以也不用担心会乱掉。关键就是得有个三五人的核心开发团队,不仅自己写还要做code review
#49 - 2015-9-2 09:41
(Across the Great Wall we can reach every corner in ...)
我先fork一下
#50 - 2015-9-2 12:06
代码和数据库的问题都可以通过流程来控制,最麻烦的还是选人的问题吧,先着眼于熟悉的人会比较好吧
#51 - 2015-9-5 18:02
关键是,Bangumi未来要发展成什么样子?
核心功能是Wiki?点格子?条目讨论?社区文化?
#52 - 2015-9-5 19:38
(bgm37)

总之先来留个名字先……
#53 - 2015-9-5 19:43
想了想,有条介于重构全新版本和维护老代码之间的想法

可以在保持原有逻辑的基础上,把API做全了,OAuth做完善了

然后坐等各路app绽放(bgm24)毕竟2015年了,指望PC主站老实说很难指望的上。有完善的API的话,PC站也一样会有人来做壳子的

不过维基部分可能还得以PC站为主,不过维基参与是可耻的零蛋所以没啥想法……
#54 - 2015-9-5 19:53
(唯漫画和傲娇不能辜负。)
嘛, bug确实挺多的…
不过我更好奇roadmap里都计划什么新功能了。
#55 - 2015-9-5 20:38
(丧典型)
观望 没什么能贡献的地方 一直都很喜欢bangumi 也因为sai和bgmer众而开始接触一些低级技术方面的事 大学也受此影响希望攻读计算机/工科相关专业 期待bangumi越来越好 可以维持像以往一样的氛围。
#56 - 2015-9-5 20:46
(Q, ∑, δ, q0, F)
我只能看看。
#57 - 2015-9-5 20:52
(Q, ∑, δ, q0, F)
既然是这样,那么不如趁此机会决定一下未来的发展,需要哪些功能,不需要哪些功能,我希望应该要精简发展,甚至于超展开与主站分离。
#58 - 2015-9-6 10:28
(Viro kaj virino. Popolo distingas ni en du tipoj.)
看了看上面的回复,
好像有不少人主张直接重构整个站子,
如果我是 sai 的话应该很难过……
自己做的东西马上就被否定了,
即使是自己已经知道老代码难维护的状态下


基本上也没啥新功能需要加的吧(Bangumi 大冒险么),
感觉都是各种要修的 Bug
#58-1 - 2015-9-6 12:20
高原
有各种想要的新功能...

什么时候才开放功能点菜...
#58-2 - 2015-9-6 22:21
fantasy
voiceover(id: voiceover) 说: 有各种想要的新功能...

什么时候才开放功能点菜...
10年后bangumi拥有了外卖的功能,成为了一个商业帝国,造就了一番神话。
#58-3 - 2017-10-7 08:30
mono
以前我也喜欢砍掉重练 (可能是为了爽),近几年开始觉得渐进式的改不容易做 (知识,观察力,技术,心理都可能成为障碍),效用却更大。
而且bgm这个样子已经习惯了 (bgm39)
#59 - 2015-9-6 22:16
后排兹词。
#60 - 2015-9-6 23:57
(你老婆真棒)
最近越来越觉得团队开发就是个坑(bgm38)
主要看是看人吧,人选得不好的话估计会坑得更厉害。

某M站自从团队开发之后进度简直....说白了沟通成本实在是太重要了,一群人不在一个房间里日夜干活真心没法控制,现有的无论是git还是svn都排不上用场,因为偷懒的人实在是太多,分开工作之后一个两个都想着别人先完成才轮到自己。写代码的指望美工先完成图,美工指望着产品先做出规划,产品指望着boss下达更详细指令(ry。于是根本没法如期完成,时间表一拖再拖到后面boss自己都有点想放弃了(bgm93)
#60-1 - 2015-9-7 00:16
BinotaLIU
#14 我提过,
用 Slack 来沟通,
虽然我并不知道国内 Slack 的访问速度如何……
不过总觉得选出来的团队成员将都是海外党 (bgm38)
#60-2 - 2015-9-7 00:23
bi119aTe5hXk
BinotaLiu 说: #14 我提过,
用 Slack 来沟通,
虽然我并不知道国内 Slack 的访问速度如何……
不过总觉得选出来的团队成员将都是海外党
其实这些管理的东西国内都有,重点是没人参照指示完成,人都是懒的...真要拖的话上面也没办法。
#60-3 - 2015-9-7 00:31
BinotaLIU
bi119aTe5hXk(id: billgateshxk) 说: 其实这些管理的东西国内都有,重点是没人参照指示完成,人都是懒的...真要拖的话上面也没办法。
其实用 Slack 的好处就是学习成本比 IRC 低,
即使是麻瓜也能轻松上手使用,
总比用 Q 群好

今年台湾 COSCUP 就用了 Slack ,
Redmine 开工单指定某人做某件事,
时间到了 bot 自己在 Slack 上 @ 当事人要做事,
当然可以羞耻 Play 直接在公开的 Channel 上 @ 当事人,
然后群众一起盯着当事人做事 (bgm38)

Slack 即使作为聊天软件也能有更多玩法 (bgm38)
#60-4 - 2015-9-7 00:49
bi119aTe5hXk
BinotaLiu 说: 其实用 Slack 的好处就是学习成本比 IRC 低,
即使是麻瓜也能轻松上手使用,
总比用 Q 群好,

今年台湾 COSCUP 就用了 Slack ,
Redmine 开工单指定某人做某件事,
时...
感觉然并卵..
人家要是不常上线的话在那里公开啥play都没用,毕竟有些时候码农在工作时是不会去管什么SNS的...

所以还是得看人...得找那些真心想去为这个projcet尽心尽力的...而不是那种只是为了参加project要个名声的(
#60-5 - 2015-9-26 18:39
upsuper
bi119aTe5hXk 说: 感觉然并卵..
人家要是不常上线的话在那里公开啥play都没用,毕竟有些时候码农在工作时是不会去管什么SNS的...

所以还是得看人...得找那些真心想去为这个projcet尽心尽力的...而不是那...
Slack的话,@会发邮件的……不过国内的人看邮件吗?我是每天早上醒来发完早安推的第一件事就是看邮件(
#61 - 2015-9-7 01:42
(我曾与你一同呼吸,那些乘着星辉的凉风 ... ... ... ... ...)
表示愿意协助运维,代码无力,我看看就好_(:зゝ∠)_
#62 - 2015-9-7 02:09
终于要有所改变了
#63 - 2015-9-12 15:26
(平行)
Any progress?
#64 - 2015-9-12 19:50
(抚君金错刀,怜君夺锦才)
(不沿用codebase直接)每人山寨一份比赛谁做得最好用谁的?
#65 - 2017-7-3 23:55
夭折?
#66 - 2017-7-4 00:22
(人型自走单线程大脑培养皿#5)
功能全靠用户写脚本
#67 - 2017-7-4 09:45
(noop)
还不如干脆开源然后彻底社区化开发。还可以建个测试站,用来测试新功能。
#68 - 2017-9-27 23:01
所以这个issue已经算是关了吗?
很想为Bangumi的长久存在做贡献。
#69 - 2017-10-7 03:14
会PHP,大概可以做把脚本搬运到后端这种级别的体力活 T_T
#70 - 2017-10-7 09:23
(汝视视汝)
想到一种可能的形态:

1. 核心团队分析需求,考虑一个功能的输入/输出
2. 社区签个CLA,为此功能写代码 (最简单是无状态代码,如果是有状态代码还需要先限定能保存状态的设施)
3. review后由核心团队部署,然后从主站RPC call 2. 中的代码,完成整个功能并开放

写完后感觉就像服务器端的用户脚本。

好处: 不用开放核心代码 / 不要求特定语言 / 核心团队要做的事较少,review也可给社区做

只是有点太...工程了,气氛不一定合适。