OpenPETRA Architecture Team: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
(Remove duplicate logging)
Line 46: Line 46:
* [[Class naming]] - Should all classes start with "T"?
* [[Class naming]] - Should all classes start with "T"?
* [[Directory structure]] - The directory structure does not fit together with architecture. Difficult for new people to find, what they are allowed to use and where to find classes.
* [[Directory structure]] - The directory structure does not fit together with architecture. Difficult for new people to find, what they are allowed to use and where to find classes.
* [[Error handling]] - We do not have a consistent way of handling error situation. We need a concept for client and server error handling. bad example: ExecuteAction in Ict.Common.Controls IctTask.cs returns String zurück. This should be shown in TaskListMouseUp with WriteToStatusBar.


==Decisions Taken==
==Decisions Taken==

Revision as of 15:56, 24 Ocak 2011

What is the Architecture Team?

A group of people within the openPETRA development team that looks at and improves architectural issues of various kinds.

Team Members

The openPETRA Architecture Team currently consists of christiank and MathiasG. They were nominated to that job by the the other openPETRA core developers at an openPETRA meeting in Carlisle (Nov.30th - Dec.2nd, 2010).

The members of the Architecture Team do not work full-time on architectural issues; rather they are 'normal' openPETRA developers who can be contacted about architectural issues and who are pro-actively looking for architectural issues as they go about their development work. They might work full-time on issues for a certain time as the need arises.


Purpose of the Architecture Team

The Architecture Team...

  • proactively identifies issues in the architecture or development process of openPETRA and highlights them to the development team.
  • investigates issues of the architecture or development process of openPETRA as identified by other development team members.

and...

  • comes up with proposals on how to improve identified issues.
  • implements changes to resolve or improve the identified issues themselves, or delegates the implementation of changes to another member of the development team, depending on whatever is seen as best and who/if somebody is available for that.
  • creates and maintains documentation on the topics of
    • openPETRA architecture
    • development process of openPETRA


Discussions

Current Discussions

The list below contains discussions on current topics.

These are discussions only and might result in one or the other decisions!

Proposals for Potential Topics for Further Discussions

The list below contains proposals for discussions on topics that we might want to look at. There is no particular order.

These are discussions only and might result in one or the other decisions!

  • Class naming - Should all classes start with "T"?
  • Directory structure - The directory structure does not fit together with architecture. Difficult for new people to find, what they are allowed to use and where to find classes.
  • Error handling - We do not have a consistent way of handling error situation. We need a concept for client and server error handling. bad example: ExecuteAction in Ict.Common.Controls IctTask.cs returns String zurück. This should be shown in TaskListMouseUp with WriteToStatusBar.

Decisions Taken

  • Other Source Code Versioning System than git: Moving to Bazaar after evaluation (Dec. 7th, 2010, architecture team meeting).
    • Move to a Bazaar Repository completed on Dec. 14th, 2010, after two days of intensive evaluation.


Meeting Notes