Page "Proposals/BEP-0013" was changed by thimal Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0013?action=diff&version=2> Revision 2 Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0013 ========================================================================= --- Proposals/BEP-0013 (version: 1) +++ Proposals/BEP-0013 (version: 2) @@ -1,59 +1,121 @@ -= BEP <BEP number> : <BEP title> #overview += BEP 13 : Dynamic client-side autocompletion features for the Apache Bloodhound ticket system #overview [[PageOutline]] -|| '''BEP''' || <BEP number> || -|| '''Title''' || <BEP title> || +|| '''BEP''' || 13 || +|| '''Title''' || Dynamic client-side autocompletion features for the Apache Bloodhound ticket system || || '''Version''' || <leave blank> || || '''Last-Modified''' || <leave blank> || -|| '''Author''' || Author With Email <[email protected]>, Author Name Only, or The Bloodhound project (see [wiki:/Proposals#bep-header-preamble BEP preamble explained]) || +|| '''Author''' || Thimal Kempitiya <[email protected]> || || '''Status''' || Draft || -|| '''Type''' || <BEP type (see [wiki:/Proposals#bep-types BEP types explained])> || +|| '''Type''' || Standards Track BEP || || '''Content-Type''' || [wiki:PageTemplates/Proposals text/x-trac-wiki] || -|| '''Created''' || <leave blank> || -|| '''Post-History''' || <leave blank> || +|| '''Created''' || || +|| '''Post-History''' || || ---- == Abstract #abstract -<Delete text in this section and add a short (~200 word) description of the technical issue being addressed. Take a look at sample abstract below> - -This template provides a boilerplate or sample template for creating your -own BEPs. In conjunction with the [wiki:/Proposals general content guidelines] and the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] -, this should make it easy for you to conform your own -BEPs to the format outlined below. See [#howto How to Use This Template] for further instructions. - -**Note**: if you are reading this template via the web, you should first try to create a new wiki page by selecting `ProposalsRst` |page template guide|. **DO NOT EDIT THIS WIKI PAGE IN ORDER TO CREATE A NEW BEP! ** - -If you would prefer not to use WikiFormatting markup in your BEP, please see [wiki:/Proposals/Formats/RestructuredText reStructuredText BEP guidelines]. - -== Motivation == - -<The motivation is critical for BEPs that want to change the copy of ''Trac'' patched using vendor branch . It should clearly explain why the existing ''Bloodhound'' solution is inadequate to address the problem that the ''BEP'' solves. ''BEP'' submissions without sufficient motivation may be rejected outright. > +Ticket system need to assist users when creating and modifying ticket to reduce potential errors and to minimize the amount need to type by the users by auto completing the fields. == Proposal #proposal -<The technical specification should describe any new features , detail its impact on the components architecture , mention what plugins will be included as a result , whether they are hosted by [http://trac-hacks.org trac-hacks.org] or not , and any other relevant technical subject . The specification should be detailed enough to allow competing, interoperable implementations for any of the current supported database platforms (e.g. ''SQLite'', ''Postgres'', ''MySQL'') and server technologies (e.g. ''Apache HTTPD server'', ''nginx'', ''mod_wsgi'', ''CGI'').. > +Detailed Description of the Project + +Project is to enhance the ticket system of the Apache Bloodhound. Ticket System should assist the user by auto completing and giving suggestion when user type in ticket creating and modifying process. This will reduce the typing of users and assist them and also reduce the potential of errors. + +This project will enhance the bloodhound ticket system in the following way. + +Autocomplete the Owner and Cc fields from a list of valid users. +Autocomplete the keywords from list of keywords that have been user to date +Search for duplicate tickets as the ticket summary is entered +Project will have two distinct parts plugin component in server side and client side impementation in ajax, javascript (jQuery and bootstrap) + +Deliverables + +Main aim of this project is to develop a module that can assist the users in the ticket creating and modifying process by auto-completing the field values. Project will deliver three main components + +Keyword Suggest Component + +This component will suggest keywords in the existing tickets and suggest them in order of the frequency of usage ( or alphabetical order) and according to the combination of characters entered by the users. Keywords list will be suggest by only pressing the enter key according to the frequency of usage. Suggest these keywords without case sensitivity of user entered characters. + +Duplicate Ticket Search Component + +This will show list of related tickets based on the summary field and if possible with description field (need to check the performance) on the relevant product. Suggest list have maximum limit (limit need to decide with discussion with community). + + + +Autocomplete Users Component + +This will show list of users in Cc field and Owner field. It show list of usernames according to the keys user press. == Rationale #rationale -<The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other issue trackers or ''Trac'' hacks . The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. Take a look at sample rationale below> +There are Trac Hack plugins which will provide the similar features to this ( autocomplete user plugin, duplicate search plugin and keyword suggest plugin). But they are not supporting the bloodhound theme or the bloodhound multi products. Proposed solution will provide the these features which will be work with bloodhound theme (jQuery and bootstrap) and work with multi product environment. Proposed solution will be work as a plugin with 3 components. So the users can enable or disable features as they need. +One alternative to this is build these fractures as internal part of bloodhound, but then it may not be enable or disable -''BEP'' submissions come in a wide variety of forms, not all adhering to the format guidelines set forth below. Use this template, in conjunction with the [wiki:/Proposals general content guidelines] and the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines], to ensure that your ''BEP'' submission is easy to read and understand. +== Approach #Approach -This template allows to create BEPs and is very similar to [http://www.python.org/dev/peps/pep-0012 PEP 12] . However it has been optimized by moving long explanations to the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] . If you are interested take a look at the [?action=diff&old_version=1 differences]. The goal is to redact new BEPs just by following in-line instructions between angle brackets (i.e. **<** **>**) . Even if this will allow to write BEPs faster , it is highly recommended to read the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] at least once in your lifetime to be aware of good practices and expected style rules . +Existing autocomplete plugin of trac give good insight about the structure (keyword Suggestion Plugin, Duplicate Ticket Plugin , Autocomplete User Plugin). for the basic structure I used the same structure in these plugin. -== How to Use This Template #howto +Here is rough description about what I'm going to do, -<BEPs may include further sections. This is an example.> +There are main two approaches, either to develop this as plugin to bloodhound or develop as core part of the bloodhound. I discussed this in developer mailing list and best approach I thins suitable is develop as a plugin with three components KeywordSuggest, DuplicateTicketSearch, and AutocompletUsers. But this may change according to the feedback from the community. -Quick edits will consist in following the instructions inside angle brackets (i.e. **<** **>**) . That should be everything needed to write new BEPs. To be more informed about advanced considerations please read the [wiki:/Proposals general content guidelines] and the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] . If there is no point in including one of the sections in this document then feel free to remove it. +KeywordSuggest -== Backwards Compatibility #backwards-compatibility +This is the component to assist users with the keyword suggestion. -<All BEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ''BEP'' must explain how to deal with these incompatibilities. ''BEP'' submissions without a sufficient backwards compatibility treatise may be rejected outright. > +Back end part need to access the database of the existing ticket to get detail about the keywords and need to keep track of the frequency of each keyword used irrespective of the case sensitivity of characters. + +Getting data from database related to keywords may be a problem with the performance. As solution to this I hope to use a plain text list of keywords and to keep track of frequency of each keyword. So the keywords can directly can be get from list and need to populate dynamically the list when user added new keyword. Also need to populate the list for the first time when starting the plugin. + +In front end need to create a better output for the keyword entering and display available keyword for the ticket. + +When entering new keywords plugin will suggest keywords base on the characters and can enter one keyword by pressing enter, to add this feature and to give better look my idea is to used the bootsrap tags input. So we can enter keywords by pressing enter key and remove them by clicking the x on keyword. + +DuplicateTicketSearch + +This will show list of related tickets to users to avoid duplicates. + +For this it need to use the BloodhoundSearch API, But due to the complexity in powerfulness of BloodhoundSearch API I hope to start with the TracSearch API and get the component to work with the TracSearch API and then move into the BloodhoundSearch API, as a incremental development. (need to check the possibility to use the Query API, I have not done many research on this so need to do bit research on this). + + + +AutocompleteUsers + +This will show list of users in Cc field and Owner field. + +AutocompleteUsers component, in back end is similar to the keywordSuggest component. So for this also I think it is better to user separate plain text to get data which will be dynamically populate when new users added. + +For the frond end it has two fields to update. Cc field would be same as the keyword field and owner field will give list of users according to the keys users type and only username can enter. + + +== Approximate Schedule #Approximate Schedule + +Gsoc will be for 14 weeks and here is rough estimation of the work break down. But this will be change according to the work flow and the discussion with bloodhound community. + +community Bonding period: + +week 1-3 : start with the keyword suggest component and autocomplete user component, and create basic component for plugin. Added the plain text list + +week 4-5: Do the front end of keyword suggest and autocomplete user components. Test it with bloodhound environment without the BlooodhoundMultiproduct plugin add test cases. + +week 6-7:Test the keyword suggest and autocomplete user components with BlooodhoundMultiproduct plugin and add necessary test cases. + +Mid Term Evaluation + +week 8-9-: start with the duplicateSearch component. Start with the trac Search api + +week 10-11: add the front end for the duplicate search and test it. Expand this to work with BloodhoundSearch API. Test it with bloodhound environment without the BlooodhoundMultiproduct plugin add test cases. + +week 12-13 : Test the duplicate search component with BlooodhoundMultiproduct plugin and add necessary test cases. + +week 14 : complete test for plugin and add documentation + +Final Evaluation == Reference Implementation #reference-implementation @@ -73,16 +135,12 @@ == References #references -<List the references included in BEP body> - 1. PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton - http://www.python.org/dev/peps/pep-0001/ - 2. PEP 9, Sample Plaintext PEP Template, Warsaw - http://www.python.org/dev/peps/pep-0009 - 2. PEP 12, Sample reStructuredText ''PEP'' Template, Goodger, Warsaw - http://www.python.org/dev/peps/pep-0012/ - 3. http://www.opencontent.org/openpub/ + 1. Keyword Suggest Plugin :http://trac-hacks.org/wiki/KeywordSuggestPlugin + 2. Autocomplete User Plugin :http://trac-hacks.org/wiki/KeywordSuggestPlugin + 3. Duplicate Search Plugin : http://trac-hacks.org/wiki/KeywordSuggestPlugin + == Copyright #copyright <In this section all licensing issues should be meticulously exposed . Library and plugin dependencies are among the most important topics . On the other hand each BEP will be explicitly labelled with a copyright statement like shown below, so should not change that. Requests for a different copyright statement have to be posted to [email protected] . For more details consult [wiki:/Proposals#what-belongs-in-a-successful-bep BEP structure explained] .> -------8<------8<------8<------8<------8<------8<------8<------8<--------
-- Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0013> Apache Bloodhound <https://issues.apache.org/bloodhound/> The Apache Bloodhound issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0013' page. If it was not you, please report to .
