Merge pull request #219 from alimy/pr-release-docs

optimize Makefile to add docs directory to release zip file

Makefile

@@ -10,7 +10,7 @@ CGO_ENABLED := 1
 endif
 
 RELEASE_ROOT = release
-RELEASE_FILES = LICENSE README.md config.yaml.sample scripts
+RELEASE_FILES = LICENSE README.md config.yaml.sample scripts docs
 RELEASE_LINUX_AMD64 = $(RELEASE_ROOT)/linux-amd64/$(TARGET)
 RELEASE_DARWIN_AMD64 = $(RELEASE_ROOT)/darwin-amd64/$(TARGET)
 RELEASE_DARWIN_ARM64 = $(RELEASE_ROOT)/darwin-arm64/$(TARGET)

docs/proposal/003-关于Followship功能项的设计.md

@@ -1,28 +1,60 @@
 | 编号 | 作者 | 发表时间 | 变更时间 | 版本 | 状态 |
 | ----- | ----- | ----- | ----- | ----- | ----- |
-| 003| 北野 | 2022-11-04 | 2022-11-04 | v0.0 | 提议 |
+| 003| 北野 | 2022-11-04 | 2022-11-21 | v0.1 | 提议 |
 
 ### 关于Followship功能项的设计
- ---- 这里写简要介绍 ----
+ Followship是实现类似Twitter Timeline模式**关注者模型**的时间线信息流，广场推文列表的生成将主要与推文时间、用户的关注者相关。Twitter的推文消息流是非常智能的，用户体验也非常好，这得益于其背后的智能推荐算法以及完善的关注者模型体系，当然还有很多其他机制共同作用下的结果。本提按作为一个总纲为paopao-ce引入类似的机制，这将是一个持续完善的缓慢过程，一切都是为了用户体验，用户就是上帝，用户需要什么，paopao-ce就努力提供什么！
 
 ### 场景 
-
+* 站点用户基数达到一定规模，推文总量很多、推文更新很快，需要一种机制更智能的生成广场推文列表改善用户体验；
- ---- 这里描述在什么使用场景下会需要本提按 ----
+* 单纯的想为站点引入关注者模型体系；
 
 ### 需求  
-实现类似于Twitter的追随者关注模式的推文传播模型，使得广场页面可以浏览已关注用户的推文。   
+#### 基本需求  
-TODO-TL;DR...
+* 实现类似于Twitter的**追随者关注模式**的推文传播模型，使得广场页面可以浏览已关注用户的推文； 
+* 提供 `关注/取消关注` 用户的机制；
+* 浏览 `用户关注者` 列表的机制；
+* 浏览 `用户追随者` 列表的机制；
+* 用户主页显示 `关注者/追随者` 计数，并作为入口进入对应浏览 `关注者/追随者` 列表的页面；
+* 广场推文页面 依据 **关注者模型**体系生成个性化推文列表；
+
+#### 可选需求  
+* 建立 **发现机制(Discover)** 为用户 *智能推荐* 用户可能会**感兴趣、值得关注**的用户；
+* 同上，广场推文页面可以附带一些**被推荐的推文**，这些推文不属于关注用户的推文，但是与关注用户相关，比如是用户关注者的关注者、热度用户等；
  
 ### 方案
 
-TODO
+#### 方案一  (仅使用后端关系数据库MySQL/Sqite3/PostgreSQL满足基本需求)
+* 提供 `关注/取消关注` 用户的机制  - 前端/后端
+* 浏览 `用户关注者` 列表的机制  - 前端/后端
+* 浏览 `用户追随者` 列表的机制 - 前端/后端
+* 用户主页显示 `关注者/追随者` 计数，并作为入口进入对应浏览 `关注者/追随者` 列表的页面 - 前端/后端
+* 广场推文页面 依据 **关注者模型**体系生成个性化推文列表 - 后端
+* 发送推文时，默认可见性为 `公开`, 公开的语义将是`关注者可见`, 因此用户如果没有登入或者没有关注任何用户，广场推文列表将只有自己的私密推文或者是空的 - 前端/后端
+
+#### 方案二 
+在方案一的基础上通过引入 *图数据库* 实现可选需求。待研究、设计～
+
 
 ### 疑问
 
-1. 如何开启这个功能？   
+1. Friendship与Followship这两功能项是否可以共存还是互斥呢？   
+    理论上这两个功能项是可以共存的，如果设置成共存，就需要同时提供这两个机制的UI交互，同时广场推文列表的生成机制也需要做相应适配，可能会比较复杂。前期开发将把这两个功能设置为互斥的，即**用户关系模型**只能设置为其中之一，待两个功能项都趋于稳定后，再测试这两个功能项共存后的用户体验，如果效果还不错就引入共存机制。
 
-TODO
+1. 如何开启这个功能？   
+    在配置文件config.yaml中的`Features`中添加`Followship`功能项开启该功能：
+    ```yaml
+    ...
+    # features中加上 Followship
+    Features:
+    Default: ["Meili", "LoggerMeili", "Base", "Sqlite3", "BigCacheIndex", "MinIO", "Followship"]
+    Base: ["Redis", "PhoneBind"]
+    ...
+    ```
 
 ### 更新记录
 #### v0.0(2022-11-04) - 北野
-* 初始文档， 先占个位置
+* 初始文档， 先占个位置；
+
+#### v0.1(2022-11-21) - 北野
+* 添加初始内容；

pkg/debug/pyroscope_embed.go

@@ -44,5 +44,4 @@ func StartPyroscope() {
 		c.AuthToken = s.AuthToken
 	}
 	pyroscope.Start(c)
-
 }