Wytyczne dotyczące przesyłania produktów do pracy

W ramach ostatecznej oceny wszyscy uczestnicy programu muszą podać link do swojej pracy w programie. Nieprzestrzeganie zasad może spowodować niezaliczenie programu. Możesz to zrobić na kilka sposobów. Prosimy o uważne przeczytanie tego dokumentu.

Te linki będą opublikowane w publicznym archiwum projektów GSoC. Pomagają też w zaprezentowaniu pracy wykonanej w ramach programu. Są one również świetnym sposobem na powrót do nich z myślą o przyszłych pracodawcach. Chcesz, aby ludzie szybko wiedzieli, jakie były cele Twojego projektu, co udało Ci się osiągnąć, gdzie jest Twój kod i jakie są możliwe dalsze kroki.

Najlepsze przykłady, jakie widzieliśmy w ostatnich latach, to „raport końcowy” zawierający:

  • Krótki opis celów projektu.
  • Co zrobiłeś.
  • Obecny stan.
  • Pozostało do zrobienia.
  • Który kod został scalony (lub nie) na wyższym poziomie.
  • wyzwania lub ważne informacje uzyskane w trakcie projektu;

Aby zapoznać się z przykładami, zacznij od Listy projektów 2022, wybieraj losowo projekty i kliknij ZOBACZ KOD. Pamiętaj, że wiele z tych projektów nie jest zgodne z naszymi sugestiami, co oznacza, że utrudniają im prezentowanie swojej pracy.

INFORMACJA DLA WSPIERAJĄCYCH: po przesłaniu ostatecznej wersji projektu możesz je edytować aż do ostatecznego terminu oddania zadania.

Udostępnij link PRZED przesłaniem oceny swojemu mentorowi, aby mieć pewność, że spełnia on jego oczekiwania.

Wymagania

  • Rozpoznanie wykonanej pracy musi być łatwe. (czyli np. zmian wprowadzonych przez Ciebie lub nowego kodu).
    • Gdy użytkownik otwiera podany adres URL, powinien wyraźnie wiedzieć, na czym polegała czynność, bez potrzeby wykonywania przez niego dodatkowych czynności związanych z przeglądaniem treści.
  • Powinien znajdować się w stabilnej lokalizacji. Po przesłaniu adresu URL nie można go zmienić.
  • Ktoś inny powinien mieć możliwość wykorzystania treści w miejscu docelowym linku (lub odniesienia do niego), aby rozszerzyć Twoją pracę.
    • Jeśli Twoja praca zostanie w 100% ukończona, będzie można jej użyć.
    • Jeśli Twoja praca nie została w 100% ukończona, powinna być jasne, co należy zrobić.

Dobre przykłady

Nie musisz wykonywać wszystkich tych czynności, ale to kilka sposobów, aby spełnić wymagania.

  • Utwórz posta na blogu, stronę internetową lub publiczny katalog GitHub z opisem wykonanej pracy oraz linkami do utworzonych przez Ciebie zatwierdzeń i repozytoriów. Jeśli jest jeszcze coś do zrobienia, zrób to. Możesz też udostępniać wyróżnione fragmenty lub wyzwania.
    • ❗ To jest najlepsza opcja, ponieważ umożliwia łatwe dołączenie dużej ilości informacji. Jest to dobre, ponieważ jasno pokazuje, jaka czynność została wykonana, a także ułatwia innym użycie i zrozumienie kodu.
  • Możesz użyć tego linku, jeśli korzystasz z GitHuba i 1 żądanie pull Twojej pracy obejmuje całą Twoją pracę.
    • Upewnij się, że opis żądania pull jest szczegółowy. (sugestie dotyczące treści posta na blogu znajdziesz powyżej).
    • Pamiętaj, aby w opisie wyraźnie zaznaczyć, że jest to wydarzenie Google Summer of Code.
    • Jeśli po zakończeniu GSoC żądanie pull będzie wymagało więcej pracy, zapisz ostatnie zatwierdzenie GSoC.
    • ❗ Ten przykład ma tę zaletę, że zawiera historię zmian, listę zobowiązań i komentarze do opinii w jednym miejscu.
  • Jeśli repozytorium GitHub jest przeznaczone tylko dla GSoC, dodaj plik README.md ze szczegółowymi informacjami.
  • Wyślij e-maila z linkiem powyżej na zarchiwizowane publicznie listę adresową deweloperów.
  • Na Dysku Google utwórz folder publiczny i umieść w nim wszystkie utworzone przez siebie poprawki.
  • Utwórz publiczny arkusz kalkulacyjny w Arkuszach Google i wymień wszystkie zatwierdzenia.
  • Podaj link do pojedynczego błędu, który wyraźnie zawiera odniesienia do utworu i innych odpowiednich elementów. Powinien śledzić całą Twoją pracę. Upewnij się, że zawiera on listę wszystkich zatwierdzeń lub że w inny sposób można je łatwo znaleźć.
  • Link do ujednoliconego procesu lub różnic kontekstowych zmian. Pamiętaj, aby dodać nagłówek z informacją, dla jakiego projektu jest przeznaczony i kim jesteś, dzięki czemu będą przydatne dla innych.

Złe przykłady

Nie rób takich rzeczy.

  • Link do pliku tarballowego lub zawierającego kod źródłowy całego projektu bądź katalogu roboczego. (Zbyt wiele osób zrobiło to w przeszłości, więc nie jest to przydatne dla osób, które chcą dowiedzieć się więcej o tym, co Twoja firma zrobiła).
  • Link do górnej części podstawowego repozytorium źródłowego projektu.
  • Link do Twojej kopii repozytorium źródłowego projektu.
    • Ciężko jest zobaczyć, co wprowadzasz w zmianę, ponieważ Twoja praca pokrywa się z innymi.
  • Link do strony projektu GSoC.
    • Wiemy już, co to jest (tj. https://summerofcode.withgoogle.com/projects/#1234567890).

Mentorzy

Pomóż współtwórcy prawidłowo przesłać kod. Pamiętaj, że musisz to zrobić przed ostatecznym okresem przesyłania zadań.

Sprawdź, czy...

  • Przesłane treści spełniają powyższe wymagania.
  • Kod się kompiluje.
  • Mamy dokumentację, która wyjaśnia, co i dlaczego.

Ideą GSoC nie jest to, aby współtwórcy zrzucali kod – jego kod mógł być potencjalnie przydatny w hostowanym projekcie open source.