Swing Maintenance Team

From iDempiere en
Revision as of 16:48, 30 January 2013 by Nmicoud (talk | contribs)

This page is for everyone who wants to improve the Swing client. It was done in the weekly meeting of 2013-23-01. (There is a page about Comparison of Clients also.)

Features that are worth a jira ticket and will be worked on can be collected as "blocking" on jira tracker IDEMPIERE-588 Swing Client improvement.

We began by collecting missing features:

missing features

CarlosRuiz: that one is maybe the most important IMHO - because it is creating some duplicate effort to try to maintain both different approaches to position fields
  • at the end of a process, ability to return to parameter panel


  • in progress
    • scroll wheel works in very small steps in Swing Client (IDEMPIERE-572)
    • Swing text areas break user flow when cycling focus with tab key (IDEMPIERE-573)
    • Swing AutoReducible ComboBox not reduced when used with cursor keys (IDEMPIERE-574)
    • Swing: Toolbar Button to start Process from button fields (IDEMPIERE-587)
    • Restricted items on Combobox (IDEMPIERE-90)
    • DocAction button is showing now just "Action" instead of the name of an action (part of [1])



Ticketing and Peer Review Procedures

The Team consists of

  • Nicolas Micoud
  • Thomas Bayen
  • Dirk Niemeyer
  • ...you?

Our workflow

  • everyone can write an issue into the above list of missing features
  • everyone can create a JIRA ticket. A JIRA ticket means either that the issue is of special significance or that the reporter takes responsibility that someone work on this ticket. (We do not want to create a bunch of dead tickets that noone reads and resolves.)
  • Every issue where the Swing Maintenance Team should be responsible becomes the following attributes:
- Component "Swing Client"
- Label "SwingUI"
- Link the new issue as blocking to IDEMPIERE-588 (Swing Client improvement)
  • If one wants to work on an issue he sets himself as the Assignee. (Others may comment at any time or give code if they want.)
  • If one really does work he sets the status to "Progress". Others are aware to ask him before they do code on the same issue
  • If the Assignee thinks his code is well done he changes status to "Peer Review". He needs to give a link to his contribution in the comment.
  • If one experienced member of the Swing Maintenance Team has reviewed he may reopen the ticket or mark it as resolved. This Team member includes the code into the iDempiere Swing Repository at https://bitbucket.org/tbayen/idempiere-swing
  • If another Team member (not the Assignee and not the Reviewer) has done a second review he closes the issue. After 4 weeks (and noone else complaining) the issue may be closed by anyone who thinks it is solved.
Cookies help us deliver our services. By using our services, you agree to our use of cookies.