Page "Proposals/BEP-0009" was changed by Pranayb Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0009?action=diff&version=2> Revision 2 Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0009 ========================================================================= --- Proposals/BEP-0009 (version: 1) +++ Proposals/BEP-0009 (version: 2) @@ -1,13 +1,13 @@ -placeholder for Pranay's proposal- -= BEP <BEP number> : <BEP title> #overview += BEP <BEP 0009> : <BEP customizable time series report> #overview [[PageOutline]] -|| '''BEP''' || <BEP number> || -|| '''Title''' || <BEP title> || +|| '''BEP''' || <0009> || +|| '''Title''' || <BEP customizable time series report> || || '''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''' || Author With Email <[email protected]>, Author Name Only, or The Bloodhound project (see [wiki:/Proposals#bep-header-preamble BEP preamble explained]) || || '''Status''' || Draft || || '''Type''' || <BEP type (see [wiki:/Proposals#bep-types BEP types explained])> || || '''Content-Type''' || [wiki:PageTemplates/Proposals text/x-trac-wiki] || @@ -18,68 +18,42 @@ == 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. > +The ability to generate customizable reports on Apache Blood hound rests on the underlying database schema. Currently, the ability to create reports is limited. There are some canned reports. There is also the ability to custom query based on filters and columns. However, what is not available is the ability to draw customizable reports based on other factors. The factors of interest are the time completion of tasks based on a standard deviation from an average completion time of tickets. This provides a good idea of the amount of time taken to complete tickets, against other closed tickets. This is useful because a report of the task taken in isolation is not as useful without some kind of a comparison metric in the report. == 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'').. > +Currently, the ability to create reports is limited to the following- (1) Active Tickets, (2) Active Tickets by version, (3) Active Tickets by Milestone, (4) Accepted, Active Tickets by owner, (5) Accepted, Active tickets by owner (full description), (6) All Tickets by milestone, and (7) My Tickets (8) Active Tickets, Mine first [1]. + +On front end of the custom query interface would look like the current format available at [2]. + +The additional customizable query will be ticket name, time taken, and comparison to the average time taken for past tickets. All the literature research done on task completion (i.e. ticket completion) points to a normal distribution of completion time (according to project management literature.) I suspect that what will emerge is a ‘normal distribution’ or some kind of ‘pareto distribution’ of time taken for status (closed tasks), in terms of completion time. + +On the back end, the SQL statements that will be most relevant in this case are the CREATE INDEX, SELECT, SELECT AVG, ORDER BY, and other relevant operators. I will be making use of computation on the SELECT AVG to come up with the standard deviation and variance and use this to factor into the report. + +The difficulty if two fold: +(1) limiting scope of query based on relevant tickets. +(2) Reducing query time by optimizing the query sent via the interface. +In order to combat (2), I will be utilizing the EXPLAIN QUERY PLAN to understand how the query is navigating into the data to fetch the required data, in order to optimize the path taken to extract data to come up with a report. This will be done to try and minimize the time taken. + +Additionally, It was proposed to have a sort of visualization. However, the probability of completing the visualization in the prescribed timeframe for this project is low. I will start the visualization with the possibility of continuing it beyond the project. It was proposed that the visualization would be done, once the backend coding and report structure, and the interface was sorted out and finalized. The visualization will try to graph the underlying pattern being analyzed in the report. This would allow the user to look at their report and immediately spot where they are on the average time taken by tasks. == 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> +The current ticket query allows one to run queries, but the more complex the queries get, the more the user needs to spend time understanding the underlying database schema. The ability of reports to do more complex queries for comparison reasons is good rationale for this type of a project. -''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. +When creating reports, it can get very complicated very quickly, but the idea here is not to complicate it too much and keep the reporting to a manageable level. The reports will allow the user to get a sense of the past tickets and use this data for better understanding. -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 . +The rationale for my approach is limited by the fact that the current database schema seems to limit the kind of queries that can be done. There have been some issues noted by various users of the system, particularly around milestones, and the saving of intermediate metadata. The only two fields to play around with are the ‘created’ and ‘modified’ fields. This may pose additional problems. -== How to Use This Template #howto +There are currently 563 matches for closed and open (and other status) tickets. The numbers of closed tickets are 349 tickets. The fields utilized will be ‘Created’= date and time and ‘Modified’= data and time, as well as ‘Resolution’ = fixed (or invalid, duplicate, worksforme, or wontfix). This approach seems most logical, as it uses the existing framework to try to create reports that make sense to the user. -<BEPs may include further sections. This is an example.> - -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. - -== Backwards Compatibility #backwards-compatibility - -<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. > - -== Reference Implementation #reference-implementation - -< The reference implementation **must** be completed before any ''BEP'' is given status **Final**, but it need not be completed before the ''BEP'' is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation **must** include test code and documentation appropriate for either the wiki pages in ''Bloodhound'' users guide or an specific wiki page in the [http://issues.apache.org/bloodhound issue tracker] . > - -== Resources #resources - -<Provide links to useful resources related to the subject discussed. See sample text below> - -See WikiFormatting for more help on the markup used to write wiki pages. == 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] <https://issues.apache.org/bloodhound/report> + [2] <https://issues.apache.org/bloodhound/query> == 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] .> Copyright © 2009-2012 The [http://www.apache.org Apache Software Foundation] [[BR]] Licensed under the [http://www.apache.org/licenses/LICENSE-2.0 Apache License, Version 2.0]. -------8<------8<------8<------8<------8<------8<------8<------8<--------
-- Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0009> 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-0009' page. If it was not you, please report to .
