(Add note on new IT bug policy) |
|||
| Line 24: | Line 24: | ||
Also in case of problems with the websites or the IT in general you can enter a bug in [https://bugs.meego.com/enter_bug.cgi?classification=MeeGo%20Community%20Infrastructure any of our components in bugs.meego.com] | Also in case of problems with the websites or the IT in general you can enter a bug in [https://bugs.meego.com/enter_bug.cgi?classification=MeeGo%20Community%20Infrastructure any of our components in bugs.meego.com] | ||
| + | |||
| + | The MeeGo IT team have 2 bug products: MeeGo IT Private and MeeGo IT. We use the private one for bugs which discuss secure or confidential information; sometimes we'll make a public bug private or a private bug public. The criteria are not well defined but in general we don't discuss specifics of our installation in public. Whilst we do not operate "security through obscurity", nor do we claim to be infallible - limiting information means that when we make errors, the information is less likely to leak and the window that we have to rectify the error without discovery should be larger. | ||
The MeeGo IT team takes care of the infrastructure in meego.com located at Oregon State University hosting center. It's devoted to offer the best service to the Community and to the other teams so that everyone can do his/her job without worrying nor caring about the underlying layers of the stack.
Contents |
You can find a complete list of services in this separate page with some details about them
You can find some of the processes here.
We have a mailing list where you can talk to the team in case you need us to know something or you want to know something. You can subscribe there if you want to have an idea of what we discuss in our weekly meetings.
Also in case of problems with the websites or the IT in general you can enter a bug in any of our components in bugs.meego.com
The MeeGo IT team have 2 bug products: MeeGo IT Private and MeeGo IT. We use the private one for bugs which discuss secure or confidential information; sometimes we'll make a public bug private or a private bug public. The criteria are not well defined but in general we don't discuss specifics of our installation in public. Whilst we do not operate "security through obscurity", nor do we claim to be infallible - limiting information means that when we make errors, the information is less likely to leak and the window that we have to rectify the error without discovery should be larger.