yegor256 / netbout Goto Github PK

migrated from Trac, where originally posted by yegor256 on 8-Sep-2010 2:12pm

You should review the existing version of SRS and identify 10 most critical defects in it.

Preliminary version of site design/layout you can find here: http://linux.fazend.com/p/netbout/trunk (the same login/password as in Trac).

Please report each defect in its own ticket and assign them to the SRS component. I already set the budget for the ticket, if it's not enough, please let me know. If it's OK, please go ahead.

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:16am

What is the interest of the owner of the NetBout service? As far as I understand the main goal of the service is a profit of the owner. It's not clear at this point if the interest is already in the ActorHelper usage price or manufacturers of the third-party software pay to the owner of the service for the placement of their tools on the site? From my point of view this aspect is important to be described.

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by netcoderpl on 13-Sep-2010 1:02pm

Since the system should be rally fast and scalable, we may fail with shared-hosting environment.

Access to server configuration may be required for guarantee QOS1 and QOS2.

Key concerns are,

• will we have access to MySQL config, to make sure we can use allowable memory effectively (we should reduce costly random reads from disk).
• will we can install any software on production server?

We may need

• really fast search engine like Sphinx
• PHP accelerator APC, thanks for that I think we can stay with ZF
• some Apache mods like "mod_deflate, mod_expires, mod_headers" to reduce http request count or alternative http server like nginx.
• memcached as cache backend

migrated from Trac, where originally posted by yegor256 on 13-Sep-2010 1:04pm

You should fix 10 defects related to SRS. Full list of defects will be provided in this ticket later (when they are discovered and documented). The budget for this task is calculated assuming that one ticket takes 30 minutes to resolve.

migrated from Trac, where originally posted by yegor256 on 13-Sep-2010 12:55pm

In this task we should review SRS document in its current version and document 10 defects. Every defect should be documented in a separate ticket.

This is where you can find a preliminary user interface of the product: [http://linux.fazend.com/p/netbout/trunk]

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 9:21pm

If used as CRM, there should be possibility for users to give his real name and surname, or company name to be used in search and in conversations.

migrated from Trac, where originally posted by yegor256 on 7-Sep-2010 11:22am

The SRS of the project is still in a very immature state. We still don't know all the functionality the system might have in the future. Thus, the database schema has to be very flexible for future changes. We may fail to design it this way, and if it happens the consequences will be severe for the entire project.

The key concerns/questions are:

• how we will register users which don't have accounts with us?
• in the future users may be grouped into "teams" or "companies", how we will take this into account?
• how about searching functionality in multi-language environment?
• how about performance? the site should be very fast, and SQL should not become a bottleneck in the future.

More questions will arise in the future.

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 9:08pm

Mentioned in UC10, but it should be extended with search for users within NetBout registry.

migrated from Trac, where originally posted by marko_lipo on 19-Sep-2010 2:20pm

It seems to me that time management feature is missing from NetBout properties:
I see that there is time in the message, but shouldn't there be time management feature, that sets and manages deadlines that are shared between users?

Please clarify.

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:16am

Please, describe the concept of the "stage" term on the NetBout level and on the ActorHelper level.
It's not obvious at this point.

Source ticket: #8

migrated from Trac, where originally posted by marko_lipo on 19-Sep-2010 2:22pm

I don't understand from SRS - is it possible that I create bout, and send it to many friends, however that they don't know who is participant in the bouts, and use it as one-to-one conversation with me?
It is useful when using NetBout as headhunting tool, or campaign disbursement tool...
Please feedback if my point is right.

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 9:03pm

It is mentioned in UC8 about global search for bouts. It should be defined more details.

migrated from Trac, where originally posted by yegor256 on 16-Sep-2010 11:38am

Motivated by #24.

We have to limit ActorUser-s activity in terms of sending of massive amount of unsolicited invitations (see some discussion in #24).

migrated from Trac, where originally posted by marko_lipo on 19-Sep-2010 2:05pm

I'm not sure that I understood what i meaned by tag in Netbout properties. Please explain, and if possible provide example in prototype http://linux.fazend.com/p/netbout/trunk/b/3.

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 8:46pm

Product scope should be better defined, exact features that are in and out of the scope in order to set up right architecture

migrated from Trac, where originally posted by yegor256 on 13-Sep-2010 1:05pm

We should identify targets/goals for release 0.2, and document them in [wiki:WBS] page.

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 8:50pm

There should be description in use case about creating user account process. What is used for login, password definition, account activation procedure etc.

migrated from Trac, where originally posted by yegor256 on 9-Sep-2010 12:10pm

Netbout.com is an alternative of existing blogs, forums, instant messaging tools, and emails itself. At the same time netbout.com is going to become a good replacement of CRM (custom relationship management) systems for small companies (maybe not only small).

Very important problem in all types of online communications is "unsolicited messages" (spam), which are delivered to users without their explicit consent. One of the advantages of netbout.com, comparing to other means like email and IM, is better protection against spam.

With all our good intentions we still may fail to design the SUD properly, and to guarantee spam filtering/protection to its users.

My key questions/concerns are:

• how we can analyze/identify all possible ways of sending spam through netbout.com? before we fight against them we should identify them. who, when and how will do this?
• what to do with stolen accounts? it's a very common problem, and some users may lose their accounts time to time. an intruder will get an access to all business contacts of the user..
• what about lost passwords? how secure shall our reminder be?

More questions will appear later. This risk is very related to the risk #11, about security.

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 8:57pm

This is very challenging area.. How long to keep visitor's records, do we enable history of visits etc?

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 9:27pm

Could we develop feature for workflow within a group, for example virtual teams, or within an company, that would enable to register subgroup (is it 'bout'?) and include some members in it, that proceed communication and publish deliverables of certain task. Lets say - marketing campaign within PR company will be one bout, and all participants contribute with their work and deliverables...
It's not clear from SRS and scope so far if this is possible

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:16am

Please, list and describe all the roles of the NetBout users. There is no exact list at this point.

Source ticket: #8

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:16am

It's not clear at this point how user should identity himself in the system.
What data should be used as login (id or email)? Should the captcha be used on the authentication page to protect site against bots?

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 9:11pm

It is not clear would there be and how possibility for users to offer chargeable services, like selling goods and services-

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 8:55pm

In ticket #12, CRM features of NetBout were mentioned. Should be specified with details what exactly it includes from typical CRM (friends list, client file, contact history)? Is it Social CRM? Does it enable to add personal notes about clients/friends in list? etc

migrated from Trac, where originally posted by yegor256 on 7-Sep-2010 10:35am

We should identify 5 most critical concerns about possible design/architecture. Every concern has to be documented in a separate ticket.

migrated from Trac, where originally posted by yegor256 on 9-Sep-2010 12:08pm

Since netbout.com is going to be a holder of private communications between people, it is very critical to make this storage a reliable one. Reliability means that under any pressure and in any extreme circumstances the system won't corrupt its data. The worst thing the system can do is to turn itself off.

There is a big risk that we may fail to design the system this way. Mostly because it is very difficult to test a system for reliability/consistency parameter.

My key questions/concerns:

• who, how and when will identify all possible "extreme circumstances"? where to document them? how to validate the list for completeness?
• how to document "normal circumstances"? I suppose that we should do it somewhere.
• how we can perform testing and how to document results?
• is our software platform (LAMP+ZF) reliable enough for big systems (I know that facebook.com uses the same approach), but still the question has to be asked.
• how we can guarantee reliability after testing, inside production environment? shall we design some specific phpRack tests for this?
• how we can protect ourselves against source code errors? in most cases they are the key sources of reliability problems.

More questions coming..

migrated from Trac, where originally posted by yegor256 on 13-Sep-2010 1:01pm

To implement UC7 where ActorUser accepts invitation. Minimum implementation is required. Everything that can't be implemented now shall be marked with @todo tags in the code, according to the PDD concept.

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

It's not clear how it can happen that user is already registered in the database but doesn't have ID yet (see UC6).
It looks like there are some UC-s missed in the SRS around the process of new user registration.

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by yegor256 on 1-Aug-2010 1:36pm

We have to specify initial requirements, in SRS.

• 1-b5151558/#638 (by )

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

Is there any kind of admin part in the site where, for example, the service owner can manage the price of the ActorHelper usage?

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

Please, describe the process of the new bout creation.
Currently it's not described in the SRS who and how creates new bout.
At the same time the UC3 says that the user finds the bout (UC8), reads the bout, updates the bout, exploits ActorHelper, invites participants to the bout and kicks off participants from the bout. Should be there some kind of predefined list of bouts? I thought that ActorUser should be an owner of the bout (creator) to be able to kick off participants from the bout. But in this use case he just uses the bout that already created by someone.

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:16am

Should there be some kind of moderator on the site? Is there any sence to create this role? Who will keep an eye on the activity of the users? Who will be able to delete messages left by users in case if they don't satisfy the site conditions and limitations.

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

It's not clear at this point what user should do in case if he forgot his password. Should there be some kind of secret question on the user's profile to give an ability to login the Sytem and to change the password in case if user forgot it?

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by yegor256 on 13-Sep-2010 12:59pm

To implement UC6 where ActorUser identifies himself. Minimum implementation is required. Everything that can't be implemented now shall be marked with @todo tags in the code, according to the PDD concept.

migrated from Trac, where originally posted by yegor256 on 7-Sep-2010 11:38am

Performance is a critical quality-of-service requirement in the system (see QOS1). Mostly because the system should be very convenient for routine operations (talking online). If we fail to design it this way — the consequences will be fatal.

My key questions/concerns:

• how to avoid multiple SQL requests per page and use caching?
• Zend Framework, as I know, is not a fast/light framework, will it handle massive traffic properly?
• we don't know yet how big our web traffic will be, are we ready to extend the system in the future (see QOS2)?
• in some places we will use AJAX, will these operations be fast? maybe we should implement some "delayed executions" queue?
• actually, not only AJAX, but all other web operations - maybe it's better to execute them through some queueing mechanism, instead of online?

Other questions may surface later.

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

As far as I understand steps 2 and 3 in the UC2 are alternative steps. It means that user can either join a bout or create a new one. If it's so then it's not obvious from the current UC description. Is there any way to improve the UC description in this aspect?

Source ticket: #8

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

Please, describe the process of user notification that there are some bills that need to be paid.

Source ticket: #8

migrated from Trac, where originally posted by yegor256 on 8-Sep-2010 9:47am

The graphic design/layout of the SUD is a critical factor of its success. If we fail to design the system in a convenient, attractive, modern and friendly manner the success of the entire business is at big risk.

Key questions/concerns are:

• shall we use any prototypes (existing popular websites like facebook, twitter, and similar) or we shall design from scratch?
• what comes first - simplicity'' or ''attractiveness? or they don't conflict?
• the site shall be "verbose" (shall talk a lot, explaining as much as possible), or it should be silent (like gmail.com)?

More questions are coming...

migrated from Trac, where originally posted by yegor256 on 9-Sep-2010 12:10pm

Netbout.com is going to become a CRM system and at the same time a communication instrument. Thus, our users will trust us with their private and sensitive information, just like they trust gmail.com and salesforce.com.

Thus, QOS3 is a very critical requirement and if we fail to design the system secure enough, the consequences will be fatal.

migrated from Trac, where originally posted by yegor256 on 7-Sep-2010 11:46am

ActorHelper is a third-party software that interacts with netbout.com in order to provide more powerful instruments for end users than just plain-text messages. For example, I'm talking in netbout.com with a potential job candidate. In other words, I'm interviewing him. I would like to give him a number of standard questions and receive his answers.

Plain text is not a good instrument for this. I would rather specify my questions in some simple format, provide answers and options, and instruct the machine how to use this information.

Then, the candidate passes this online questionnaire and I receive the results. Obviously, this software is not part of netbout.com, but can be provided by some third-party company. They will definitely want to charge me some fee for the using of their Helper, like $0.05 per every questionnaire filled. I will pay to netbout.com and the system will transfer this money to the author of the Helper.

We don't know now how complex these helpers will be. They might be very complex, and might include video, sound, graphics, complex documents, etc.

My questions are:

• how Helper can specify an interface of interaction between ActorUser and a "stage" of NetBout? XML? XForms? jQuery?
• maybe we may allow helper providers to upload some MVC-like Java-code to our server?
• how about interface standards? how much flexibility we can give to helper providers? can they design their interfaces with a full freedom, or only based on our CSS rules?

There will be much more questions later.

migrated from Trac, where originally posted by yegor256 on 13-Sep-2010 1:01pm

To implement UC2 where ActorUser joins NetBout. Minimum implementation is required. Everything that can't be implemented now shall be marked with @todo tags in the code, according to the PDD concept.

This task shall be started after #15 and #16.

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

As far as I understand bout is a some kind of discussion of a problem or a topic. If this so, may be it makes sence to give an ability to the bout creator to place marks to the messages or/and to say "thanks" to the message author. It will help bout members to find the most useful messages easier. Beside this users will strive for placement of useful messages known that their messages can be evaluated.

Please, advise.

Source ticket: #8

migrated from Trac, where originally posted by marko_lipo on 15-Sep-2010 8:49pm

Use cases have just main flows, mostly informal. Alternative flows to be defined.

migrated from Trac, where originally posted by yegor256 on 8-Sep-2010 2:24pm

Please, review the task #2 and risks identified by me in tickets #3, #4, #5, #6 and #7. In this task you should review the SRS and the preliminary site layout (available with the code from SVN or online at our testing server: http://linux.fazend.com/p/netbout/trunk/), identify and document 2 technical risks (architectural concerns).

We've done similar tasks before, I hope there won't be any problems. But anyway, feel free to ask. The budget for the task is set already. If it's not enough, please report here. If it's OK, please start now.

migrated from Trac, where originally posted by yegor256 on 7-Sep-2010 11:20am

The core idea behind the netbout.com system is the ability to establish online communication "bouts" between people one of who doesn't know anything about netbout, and doesn't have a netbout account. It should work like the following:

1. I have an account with netbout.com
2. I create a new bout with [email protected]
3. John receives an invitation email from netbout.com
4. John clicks the link in the email
5. John answers me in the netbout.com we page just opened
6. I reply to him and we keep talking this way

John never registers an account with netbout.com. He just talks with me, and the system remembers him. Once he wants to register an account, he can do it, and the system will attach everything that happened before to the account created.

I don't know yet how to design this mechanism properly, and what technologies we should use. My key questions:

• shall we use cookies? is it secure enough? is it convenient for the user? what if he/she changes the computer?
• what about OpenID? maybe it will help?
• what if email message is lost? or the link inside it is broken (by mail reader)?
• how about SMS interface, when the user replies without even visiting of netbout.com website? can we take this into account for the future?

There will be more questions once we make a decision about the technology to use.

migrated from Trac, where originally posted by netcoderpl on 13-Sep-2010 1:08pm

Since the searcher will be really intensively used, and will work with massive amount of text it can be performance critical part of netbout.com.

Key concerns are,

• what technology we will use (MySQL Full-Text, Sphinx, Lucene, other..)?
• how we will cache results?
• how search index will be updated to guarantee QOS1, QOS2 and QOS4?
• how searching by tags will be handled?
• should we take into account ACL support for searcher?

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

At this point description of the UC4 is very poor. It should be detailed. What does it mean to archive the bout? It looks like some kind of status of the bout but it's not clear at this point what actions can be performed upon the bout in this "status".

Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

Should the System send an email to the bout creator in case if he is offline and there new message(s) in his bout?
Please, clarify.

Source ticket: #8

migrated from Trac, where originally posted by yegor256 on 13-Sep-2010 12:53pm

Currently ambiguity of the SRS document is 0.824. We need to make it lower than 0.8. This task is going to be a small one, but necessary in order to test our mutual understanding of this metric.

Ask questions, and we resolve it together.

migrated from Trac, where originally posted by y.vedenin on 15-Sep-2010 10:17am

How notifications about invitations look? Is it an email or a private message on the site, or both?

Please, clarify.

Source ticket: #8