Issue tags

Issue Tags

You can use the tags to filter out the issue you are interested in / capable of. General description:

• Tags are in the form "Prefix Number: Description".
• "Prefix" is a single letter.

"T" -- Type

Type of the issue. The names are self-explanatory.

• T0:Bug
• T1:Enhancement
• T3:Feature
• T4:General
• T5:Question

"P" -- Position

As you know, there are conceptually three layers of SNSAPI. The "P" tags indicate the position that one issue is associated with. They are self-explanatory.

• P0:SNSAPI
• P1:Plugin
• P2:App

"S" -- Status

• S0:Plan: We are planning. e.g. discussing with potential contributors how it should be done.
• S1:Dev: Someone is working on it. If you want to contribute, find those who are mentioned in the thread. This is avoid duplicated work.
• S2:Test: Part (or all) of the functions are done. We are testing the new commits.

FAQ:

• No "S3:Done"? If sth. is done, the issue will be closed... OK, there will be reasons to close an issue: It is done; It is abandoned. For the former case, we will leave pointers in the thread (in which pull request/ commit it is done).
• Some issues have no "S" tags. Many possibilities:

1. It is not development related;
2. The solution is unclear yet;
3. No one (contributors, repo maintainers) have time at present;
4. I forget...

The rule of thumb: When you have doubt regarding the current status, please leave comments in the issue tracker or Google Group.

"I" -- Importance

The importance is just from the repo maintainer's point of view. If you think sth. is important, welcome to point it out in the issue or Google group.

• I0:Ordinary
• I1:Important

"L" -- Level

The level of difficulty. I should elaborate a bit:

• L0:Easy: The entrance level. You don't have to master Python in order to do it. As long as you have some basic knowledge (of e.g. Github, Git, Wiki, Python), you should be able to achieve the goal with documentation and Google. You can use those issues as exercises to sharpen your skill and get a feel of working with our community.
• L1:Moderate: This level requires more understanding of Python and SNSAPI. It is a good idea to use SNSAPI (e.g. CLI, demo apps) with multiple platforms before you proceed. You may need to run integration test before the code is merged. Having a good feel of the use case is esential. We welcome all forms of contributions but we should reject blind improvements. By "blind", we mean: Someone does some local modifications without testing with other components of SNSAPI. Nevertheless, feel free to issue pull requests. If there is any problem, we will feedback. Having daily use knowledge of SNSAPI will definitely reduce the feedback-fix cycle.
• L2:Advanced: This level emphasize depth of knowledge. You will dig into a problem in depth in order to solve it. e.g. an annoying bug. e.g. design pattern for a certain function. e.g. prototyping a platform with novel communication methods. Note that the "L" series is only the difficulty from our point of view. It may not suit you. For example, a Python expert who know nothing about SNSAPI may solve some "L2" problems by a glance. Highly appreciate comments from skilled developers.
• L3:Difficult: This level emphasize breadth of knowledge. You are familiar with Python and SNSAPI. By "familiar with SNSAPI", we mean a daily use experience. e.g. You are using SNSAPI to operate mutiple different platforms every now and then. Having a master undersdanding of the rationales behind SNSAPI is essential (Why it is designed this way even if it looks stupid to do so). Those issues will influence many follow-up codes, so we are serious about them. The "difficult" does not mean it is technically extremely difficult. Instead, it means it is very difficult to get things done in the right way. Bear in mind that SNSAPI is the middleware. We should consider both sides (App, Plugin) carefully for any archtectural improvements.